Value differs between debug and release: 1.0 / ((-0.0) * black_box_zero)

[jruderman]

This code has differing behavior in debug and release (playground):

fn main() {
    let black_box_zero = (std::env::args().len() - 1) as f32;
    let result = 1.0 / ((-0.0) * black_box_zero);
    let expected = f32::NEG_INFINITY;
    assert_eq!(result, expected);
}

When compiled in debug mode (without optimizations), the program produces no output.

When compiled in release mode (with optimizations), the assertion fails:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `-inf`,
 right: `-inf`', src/main.rs:5:5

(This output doesn't make sense to me: how can they be unequal, but both negative infinity?)

[jruderman]

Here's another program with similar behavior, failing only in release. Not sure if it's the same issue.

fn main() {
    let black_box_one = (std::env::args().len()) as f32;
    let result = - (black_box_one / 0.0);
    let expected = f32::NEG_INFINITY;
    assert_eq!(result, expected);
}

[SNCPlay42]

This function, based on the first code example, is misoptimized to unconditionally return false (godbolt):

pub fn foo(n: usize) -> bool {
    let black_box_zero = (n - 1) as f32;
    
    let result = 1.0 / ((-0.0) * black_box_zero);

    result == std::f32::NEG_INFINITY
}

This was not misoptimized before rustc 1.25, which upgraded LLVM to version 6.0. This appears to be a misoptimization by LLVM (Unless there's some allowed variability to do with the signs of zeroes that I'm not aware of?)

@rustbot label A-LLVM A-floating-point I-unsound T-compiler regression-from-stable-to-stable

[nbdd0121]

This C code miscompiled under Clang as well: https://godbolt.org/z/bfqoGePW1.

Confirmed to be a LLVM bug.

[SNCPlay42]

The second example does actually appear to be different - it doesn't miscompile until rustc 1.30 (godbolt) (which upgraded to LLVM 8).

[nikic]

Upstream issue: llvm/llvm-project#58046

[lukas-code]

possibly related: #55131

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[pnkfelix]

T-compiler P-high review

@rustbot assign @nikic

(also, @Mark-Simulacrum notes that since upstream llvm/llvm-project#58046 is fixed now, this issue should eventually get resolved by either an LLVM upgrade or by cherry-picking the fix to Rust's LLVM fork.)

[jruderman]

Does that fix take care of the second example?

[jruderman]

To answer my own question: both examples are fixed for me after updating rustc nightly from (9c56d9d 2022-09-29) to (8ce3204 2022-09-30)

[RalfJung]

Should we add a test for this?