`mul_add` on `*-pc-windows-gnu` returns incorrect results

[beetrees]

I tried this code (test case taken from this comment):

fn main() {
	let (a, b, c) = std::hint::black_box((-1.9369631e13f32, 2.1513551e-7, -1.7354427e-24));
	dbg!(a.mul_add(b, c));
}

I expected to see this happen: The correct result should be printed as mul_add is guaranteed to return the correctly rounded result, which is -4167095.8.

Instead, this happened: On both i686-pc-windows-gnu and x86_64-pc-windows-gnu, -4167095.5 is printed instead. This is due to the FMA implementation in MinGW being incorrect (upstream bug report). This is unsound as LLVM is allowed to rely on FMA returning correct results when optimising.

Meta

rustc --version --verbose:

rustc 1.88.0-nightly (74509131e 2025-04-29)
binary: rustc
commit-hash: 74509131e85a97353c67c503ea32e148a56cf4bd
commit-date: 2025-04-29
host: x86_64-unknown-linux-gnu
release: 1.88.0-nightly
LLVM version: 20.1.2

[beetrees]

@rustbot label +I-unsound +O-windows-gnu +A-floating-point

[ChrisDenton]

Can it lead to actually unsound optimisations in practice or is this more a theoretical?

[beetrees]

The fix for scalar evolution of functions which aren't guaranteed correctly rounded (llvm/llvm-project#90942) fixed the issue by just not doing scalar evolution on any libcalls which return floating-point numbers (relevant code), so scalar evolution won't be an issue in practice at the moment. I don't know if there are any other optimisations that depend on FMA having correct results.

[beetrees]

This will also affect Miri when run on a *-pc-windows-gnu host as Miri currently uses host mul_add to work around rust-lang/rustc_apfloat#11. cc @RalfJung