if-then-else with compare-not-equal modifies value when it shouldn't

[smanilov]

Aim

Debug a failing test in a third_party library (resurgencelabs/fraction).

Expected Behavior

Test is failing due to a bug in the library.

Bug

Test is failing due to a bug in the Noir language tools.

To Reproduce

1. checkout https://github.com/resurgencelabs/fraction
2. change Nargo.toml to use >=0.25, not exactly 0.25
3. get nargo v0.30 or later
4. issue nargo test

Test "test_add_large()" fails with the following message:

[fraction] Testing test_add_large... FAIL
Failed to solve program: 'Cannot satisfy constraint'

error: Failed constraint
    ┌─ /home/stan/code/repos/benchmarking-noir/fraction/src/lib.nr:710:12
    │
710 │     assert(compareFraction(floor(a), MAX) == 2);
    │            -----------------------------------
    │
    = Call stack:
      1. /home/stan/code/repos/benchmarking-noir/fraction/src/lib.nr:710:12

[fraction] 1 test failed

compareFraction returns 1 instead of 2.

Note: this is not a bug in the library, but rather a bug in the Noir implementation. It can be reproduced with the following snippet:

use dep::fraction::{Fraction, MAX, floor, toFraction, addFraction};

fn main() {
    let g1 = toFraction(true, 33333333, 5);
    let g2 = toFraction(true, 500000, 33333333);
    let a = addFraction(g1, g2);

    print("a: ");
    println(a);

    let f1 = floor(a);
    let f2 = MAX;

    // assert(compareFraction(floor(a), MAX) == 2);

    print("1 signs: ");
    print(f1.sign);
    print(" ");
    println(f2.sign);

    let _ = if (f1.sign != f2.sign) {
        if (f1.sign) { 1 } else { 2 }
    } else {
        print("2 signs: ");
        print(f1.sign);
        print(" ");
        println(f2.sign);
        0
    };
}

Note that in this code, "1 signs" and "2 signs" should print the same thing, because f1.sign and f2.sign are not modified in between. The output of nargo execute, however, is this:

a: Fraction { sign: true, num: 666666661, den: 100 }
1 signs: true true
2 signs: false true

Also note: using nargo debug results in the correct expected behavior:

a: Fraction { sign: true, num: 666666661, den: 100 }
1 signs: true true
2 signs: true true

Project Impact

Blocker

Impact Context

This is a serious issue that undermines the credibility of using Noir in mission-critical systems and projects.

Workaround

None

Workaround Description

No response

Additional Context

This was discovered while trying to compile a collection of working programs and libraries written in Noir.

Installation Method

Compiled from source

Nargo Version

nargo version = 0.30.0 noirc version = 0.30.0+af57471035e4fa7eaffa71693219df6d029dbcde

NoirJS Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[jfecher]

Thanks for the issue - this was caused by a faulty optimization which I've disabled in #5240. Should be fixed once that is merged.