Subnormal f64 to f32 cast is incorrect in CTFE

[cbeuw]

pub fn main() {
    let f = f64::from_bits(0x19873cc2) as f32;
    println!("{:x}", f.to_bits());
    println!("{}", f == 0.);
}

$ rustc -Zmir-opt-level=2 -Copt-level=3 repro.rs && ./repro
1
false
$ ../miri/miri run repro.rs 2> /dev/null
1
false
$ rustc -Zmir-opt-level=1 -Copt-level=3 repro.rs && ./repro
0
true

It should print 0 and true, according to the equivalent C program: https://godbolt.org/z/7Gq51a1Yh

This is probably another apfloat bug

$ rustc --version -v 
rustc 1.72.0-nightly (d9c13cd45 2023-07-05)
binary: rustc
commit-hash: d9c13cd4531649c2028a8384cb4d4e54f985380e
commit-date: 2023-07-05
host: aarch64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

(reproducible on x86 as well)

cc @eddyb @wesleywiser @RalfJung

[RalfJung]

This is strange: https://godbolt.org/z/14GxTsfoM

LLVM and Rust are both using apfloat for compile-time float computations, and yet the MIR opts produce 1 and LLVM produces 0. Is this something that was fixed in upstream apfloat but we don't have the fix yet?

[cbeuw]

Rust's apfloat port is old and unupdated for a long while. For instance #102403 was fixed upstream 6 years ago llvm/llvm-project@f2c2851

[nikic]

The relevant fix is probably https://reviews.llvm.org/D127140?

[RalfJung]

#113416 should work around this.

[eddyb]

While trying to trigger a different issue involving float<->float conversions, I believe my rustc_apfloat fuzzer (after commit rust-lang/rustc_apfloat@439177a) reproduced this one instead:

(which is good confirmation that we can find such things. too bad about the FMA NaNs polluting fuzzer outputs)

EDIT: also see the longer update post at #55993 (comment)

[eddyb]

As per #55993 (comment), this is now fixed in rust-lang/rustc_apfloat.

[cbeuw]

This should be reopened until rustc starts using the stand-alone crate

[eddyb]

Uh oh I did not do that, GH must've gotten overzealous cross-repo.

[RalfJung]

You said "fixes #113407" in that PR, GH did the rest. ;)