Sign of zero from differs between CTFE and normal execution (float % float)

[jruderman]

With this code:

#![feature(const_fn_floating_point_arithmetic)]

const fn f(one: f64) -> f64 {
    (-1.0) % one
}

const RESULT_CT : f64 = f(1.0);

fn main() {
    let black_box_one = (std::env::args().len()) as f64;
    let result_rt = f(black_box_one);
    assert_eq!(RESULT_CT.is_sign_negative(), result_rt.is_sign_negative());
}

The assertion fails: compile-time evaluation gives 0.0 while runtime evaluation gives -0.0.

This is probably relevant to tracking issue #57241.

[scottmcm]

Reminds me of #55131, though this one's probably less ugly since signs of zeros are less FUBAR than signs of NANs.

[RalfJung]

Probably another apfloat bug, either in the LLVM original or in the transpilation?
Which is even the correct answer?
Cc @eddyb @workingjubilee
Cc rust-lang/unsafe-code-guidelines#237

[eddyb]

To look at LLVM, just feed it through constant folding: https://godbolt.org/z/oWqrhKe4h

So it looks like current LLVM APFloat results in negative sign.
This remains the case even when going back to 1.20 (which should be old enough to reflect the state of LLVM at the time of the porting): https://godbolt.org/z/8dj73sEjr.

So this looks like it might be another bug like #100233 (comment) :/

---

EDIT: you don't need to run any code to see the bug in action, you can trigger it with MIR inlining: https://godbolt.org/z/nYxchqv9P

Current output (just the relevant parts):

fn f_one() -> f64 {
    let mut _0: f64;
    bb0: {
        _0 = const 0f64;
        return;
    }
}

fn minus_zero() -> f64 {
    let mut _0: f64;
    bb0: {
        _0 = const -0f64;
        return;
    }
}

[oli-obk]

So... basically const prop is unsound around floats?

[RalfJung]

The example is a CTFE bug, not a ConstProp bug.
Do we even do ConstProp on floats ourselves?

[saethlin]

Using the reproducer from #109567

Do we even do ConstProp on floats ourselves?

Yes. ConstProp disagrees with LLVM: https://godbolt.org/z/5dPrfqMYq

(once again wishing we could either pin to a nightly in godbolt or otherwise set mir-opt flags in a stable compiler, because this link will eventually not reproduce if we fix this)

pub fn make_me_a_float() -> f64 {
    -1.0 % -1.0
}

With --emit=mir we get:

fn make_me_a_float() -> f64 {
    let mut _0: f64;                     // return place in scope 0 at /app/example.rs:1:29: 1:32

    bb0: {
        _0 = const 0f64;                 // scope 0 at /app/example.rs:2:5: 2:16
        return;                          // scope 0 at /app/example.rs:3:2: 3:2
    }
}

But with --emit=llvm-ir -Zmir-enable-passes=-ConstProp we get:

define double @_ZN7example15make_me_a_float17h53a3e1048ece245eE() unnamed_addr #0 !dbg !6 {
  ret double -0.000000e+00, !dbg !11
}

[RalfJung]

#109567 has some other examples reproducing this.

[eddyb]

While trying to make progress on #113409 I noticed this was showing up as "C++ llvm::APFloat and Rust rustc_apfloat agree, but hardware disagrees", which I was confused by because I've shown above (#102403 (comment)) rustc 1.20 constant-folds it correctly in LLVM (and even rustc 1.0 does AFAICT).

But, this is not a porting bug, it's a LLVM one, fixed very soon after my port: llvm/llvm-project@f2c2851

My best guess is that LLVM was unaffected by its own bug because the host C fmod function was used instead (a LLVM commit from 2 years later, llvm/llvm-project@ed5f452 might imply something like that, but I haven't 100% confirmed that's what's going on).

---

EDIT: for the record, I would not have figured this out as easily if not for my WIP fuzzing system:

(turns out instrumentation-based fuzzers and softfloat impls are a great match, I'm guessing because of how all the special cases are handled with branches, and depend on relatively simple bitpatterns of the input)

[eddyb]

I posted a longer update to #55993 (comment) regarding the progress with the whole rustc_apfloat situation, but of note for this issue is that the WIP repo already has this bug fixed.

[eddyb]

Accidentally closed (overzealous GitHub), my bad.