Casts between floats and ints fail to roundtrip properly on `i586-unknown-linux-gnu`

[okaneco]

Doc tests introduced in #152512 for f32 and f64 failed in a rollup #152616 (comment) on the i586-unknown-linux-gnu job.

These tests as cast between i32<->f32 and i64<->f64, with no floating point arithmetic performed.

I tried this code:

{ // Max exact integer test, f32
let max_exact_int: i32 = (1 << f32::MANTISSA_DIGITS) - 1;
assert_eq!(max_exact_int, max_exact_int as f32 as i32);
assert_eq!(max_exact_int + 1, (max_exact_int + 1) as f32 as i32);
assert_ne!(max_exact_int + 2, (max_exact_int + 2) as f32 as i32);
// Beyond `f32::MAX_EXACT_INTEGER`, multiple integers can map to one float value
assert_eq!((max_exact_int + 1) as f32, (max_exact_int + 2) as f32);
}

{ // Min exact integer test, f32
let min_exact_int: i32 = -((1 << f32::MANTISSA_DIGITS) - 1);
assert_eq!(min_exact_int, min_exact_int as f32 as i32);
assert_eq!(min_exact_int - 1, (min_exact_int - 1) as f32 as i32);
assert_ne!(min_exact_int - 2, (min_exact_int - 2) as f32 as i32);
// Below `f32::MIN_EXACT_INTEGER`, multiple integers can map to one float value
assert_eq!((min_exact_int - 1) as f32, (min_exact_int - 2) as f32);
}

{ // Max exact integer test, f64
let max_exact_int: i64 = (1 << f64::MANTISSA_DIGITS) - 1;
assert_eq!(max_exact_int, max_exact_int as f64 as i64);
assert_eq!(max_exact_int + 1, (max_exact_int + 1) as f64 as i64);
assert_ne!(max_exact_int + 2, (max_exact_int + 2) as f64 as i64);
// Beyond `f64::MAX_EXACT_INTEGER`, multiple integers can map to one float value
assert_eq!((max_exact_int + 1) as f64, (max_exact_int + 2) as f64);
}

{ // Min exact integer test, f64
let min_exact_int: i64 = -((1 << f64::MANTISSA_DIGITS) - 1);
assert_eq!(min_exact_int, min_exact_int as f64 as i64);
assert_eq!(min_exact_int - 1, (min_exact_int - 1) as f64 as i64);
assert_ne!(min_exact_int - 2, (min_exact_int - 2) as f64 as i64);
// Below `f64::MIN_EXACT_INTEGER`, multiple integers can map to one float value
assert_eq!((min_exact_int - 1) as f64, (min_exact_int - 2) as f64);
}

I expected to see this happen: All 4 of these test blocks should pass

Instead, this happened: All 4 blocks failed

Probably related to #114479

Meta

I didn't see the toolchain in the log, but whatever tip of nightly was at 2026-02-14T16:31:07.2087585Z

Backtrace

---
             at /rustc/b184b22b186f12ce7b538c7857b49650d492a1fc/library/core/src/panicking.rs:80:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed::<i32, i32>
             at /rustc/b184b22b186f12ce7b538c7857b49650d492a1fc/library/core/src/panicking.rs:394:5
   4: rust_out::main::_doctest_main_library_core_src_num_f32_rs_528_0
   5: rust_out::main
   6: <fn() as core::ops::function::FnOnce<()>>::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- library/core/src/num/f32.rs - f32::f32::MAX_EXACT_INTEGER (line 528) stdout end ----
---
             at /rustc/b184b22b186f12ce7b538c7857b49650d492a1fc/library/core/src/panicking.rs:80:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed::<i32, i32>
             at /rustc/b184b22b186f12ce7b538c7857b49650d492a1fc/library/core/src/panicking.rs:394:5
   4: rust_out::main::_doctest_main_library_core_src_num_f32_rs_555_0
   5: rust_out::main
   6: <fn() as core::ops::function::FnOnce<()>>::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- library/core/src/num/f32.rs - f32::f32::MIN_EXACT_INTEGER (line 555) stdout end ----
---
   1: core::panicking::panic_fmt
             at /rustc/b184b22b186f12ce7b538c7857b49650d492a1fc/library/core/src/panicking.rs:80:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed::<i64, i64>
   4: rust_out::main::_doctest_main_library_core_src_num_f64_rs_527_0
   5: rust_out::main
   6: <fn() as core::ops::function::FnOnce<()>>::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- library/core/src/num/f64.rs - f64::f64::MAX_EXACT_INTEGER (line 527) stdout end ----
---
   1: core::panicking::panic_fmt
             at /rustc/b184b22b186f12ce7b538c7857b49650d492a1fc/library/core/src/panicking.rs:80:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed::<i64, i64>
   4: rust_out::main::_doctest_main_library_core_src_num_f64_rs_554_0
   5: rust_out::main
   6: <fn() as core::ops::function::FnOnce<()>>::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- library/core/src/num/f64.rs - f64::f64::MIN_EXACT_INTEGER (line 554) stdout end ----

@rustbot label A-floating-point O-x86_32

[nikic]

Instead, this happened: All 4 blocks failed

Can you please clarify which of the assertions are actually failing? Is it all of them?

[okaneco]

Not all of the asserts.
Checking on Compiler Explorer, it seems to only be the lines with max_exact_int + 2 or min_exact_int - 2.
When converted to floating point, their values should be the same as max_exact_int + 1 and min_exact_int - 1, respectively.

https://rust.godbolt.org/z/v63GT7srG

These are the failing f32 panic messages, f64 fails similarly (substitute in 9007199254740993 and 9007199254740992 for the corresponding values).
Trying to print or debug print the values in the failing float equality asserts causes those equality asserts to pass.

assert_ne!(max_exact_int + 2, (max_exact_int + 2) as f32 as i32);

thread 'main' (1) panicked at /app/example.rs:16:5:
assertion `left != right` failed
  left: 16777217
 right: 16777217 // Should be 16777216

assert_eq!((max_exact_int + 1) as f32, (max_exact_int + 2) as f32);

thread 'main' (1) panicked at /app/example.rs:22:5:
assertion `left == right` failed
  left: 16777216.0
 right: 16777216.0

assert_ne!(min_exact_int - 2, (min_exact_int - 2) as f32 as i32);

thread 'main' (1) panicked at /app/example.rs:28:5:
assertion `left != right` failed
  left: -16777217
 right: -16777217 // Should be -16777216

assert_eq!((min_exact_int - 1) as f32, (min_exact_int - 2) as f32);

thread 'main' (1) panicked at /app/example.rs:34:5:
assertion `left == right` failed
  left: -16777216.0
 right: -16777216.0

Failing asserts

// -Copt-level=3 --target=i586-unknown-linux-gnu
#[inline(never)]
pub fn main() {
    max_exact_f32_1();
    max_exact_f32_2();
    min_exact_f32_1();
    min_exact_f32_2();
    max_exact_f64_1();
    max_exact_f64_2();
    min_exact_f64_1();
    min_exact_f64_2();
}

#[inline(never)]
pub fn max_exact_f32_1() {
    let max_exact_int: i32 = std::hint::black_box((1 << f32::MANTISSA_DIGITS) - 1);
    assert_ne!(max_exact_int + 2, (max_exact_int + 2) as f32 as i32);
}

#[inline(never)]
pub fn max_exact_f32_2() {
    let max_exact_int: i32 = std::hint::black_box((1 << f32::MANTISSA_DIGITS) - 1);
    assert_eq!((max_exact_int + 1) as f32, (max_exact_int + 2) as f32);
}

#[inline(never)]
pub fn min_exact_f32_1() {
    let min_exact_int: i32 = std::hint::black_box(-((1 << f32::MANTISSA_DIGITS) - 1));
    assert_ne!(min_exact_int - 2, (min_exact_int - 2) as f32 as i32);
}

#[inline(never)]
pub fn min_exact_f32_2() {
    let min_exact_int: i32 = std::hint::black_box(-((1 << f32::MANTISSA_DIGITS) - 1));
    assert_eq!((min_exact_int - 1) as f32, (min_exact_int - 2) as f32);
}

#[inline(never)]
pub fn max_exact_f64_1() {
    let max_exact_int: i64 = std::hint::black_box((1 << f64::MANTISSA_DIGITS) - 1);
    assert_ne!(max_exact_int + 2, (max_exact_int + 2) as f64 as i64);
}

#[inline(never)]
pub fn max_exact_f64_2() {
    let max_exact_int: i64 = std::hint::black_box((1 << f64::MANTISSA_DIGITS) - 1);
    assert_eq!((max_exact_int + 1) as f64, (max_exact_int + 2) as f64);
}

#[inline(never)]
pub fn min_exact_f64_1() {
    let min_exact_int: i64 = std::hint::black_box(-((1 << f64::MANTISSA_DIGITS) - 1));
    assert_ne!(min_exact_int - 2, (min_exact_int - 2) as f64 as i64);
}

#[inline(never)]
pub fn min_exact_f64_2() {
    let min_exact_int: i64 = std::hint::black_box(-((1 << f64::MANTISSA_DIGITS) - 1));
    assert_eq!((min_exact_int - 1) as f64, (min_exact_int - 2) as f64);
}

---

To add more context for these numbers, (1i32 << f32::MANTISSA_DIGITS) is 16777216.

i32 values in the range of -16777216..=16777216 should round trip losslessly to f32 and back to i32 preserving their value.
Once we have integer magnitudes larger than (1 << MANTISSA_DIGITS), there's not enough precision to represent these numbers in the same byte-sized floating point type without rounding. Thus, 16777217_i32 as f32 becomes 16777216.0_f32, then returns to i32 as 16777216_i32.

The expected rounding/truncation is not happening on i586. The failing assert_eqs show that 16777216_i32 and 16777217_i32 are being converted to distinct f32 values when they should be the same. The failing assert_nes show 16777217_i32 is incorrectly returning as 16777217_i32 instead of 16777216_i32.

[tgross35]

I think this has to be an incorrect lowering of @llvm.fptosi since everything else should be the same on all targets. @quaternic or @programmerjake may have a better idea of what exactly is wrong.

Added as a related issue to #114479, even though I don't think it's the same root cause.

[programmerjake]

AFAICT it's an incorrect lowering of the sitofp LLVM instruction -- that lowers to a fild instruction which converts from an integer in memory to a f80 in a x87 register, there should be an additional step where it gets rounded to f32 by storing back to memory, but LLVM is skipping that step since IIRC the C equivalent allows that. So, yeah, it's just another case of x87 FP being broken, like in #114479.

[programmerjake]

yeah, here LLVM improperly compiles sitofp for i32 -> f32, note it generates the exact same assembly as C that casts both sides to long double (f80) before comparing, which is incorrect since large integers need to be rounded when converting to f32:
https://rust.godbolt.org/z/bMrv34jbb

#[unsafe(no_mangle)]
pub extern "C" fn bad_cmp(a: i32, b: f32) -> bool {
    (a as f32) > b
}

C that generates the exact same assembly:

_Bool bad_cmp(int a, float b) {
    long double lb = b;
    asm(""::"m"(a)); // make it load `a` last to match rustc, has no semantic effect
    long double la = a;
    return la > lb;
}

assembly:

bad_cmp:
        push    eax
        fld     dword ptr [esp + 12]
        mov     eax, dword ptr [esp + 8]
        mov     dword ptr [esp], eax
        fild    dword ptr [esp]
        fucompi st, st(1)
        fstp    st(0)
        seta    al
        pop     ecx
        ret

note how it compares immediately after the fild load-and-convert-from-integer-to-f80 instruction without properly storing back to memory to round to f32.

[quaternic]

That's nothing specific to sitofp though. On i586, LLVM just doesn't round the intermediate floating point values correctly (i.e. at all) regardless of what produced them. E.g. (x + y) - x is also miscompiled in the same way, which was causing a significant accuracy problem in libm exponential functions ( rust-lang/compiler-builtins#1021 ).