`mul_add` on `*-pc-windows-gnu` returns incorrect results
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the provided Rust reproducer on i686-pc-windows-gnu and x86_64-pc-windows-gnu, then read the linked MinGW-w64 bug about its FMA implementation. Done means mul_add produces the correctly rounded -4167095.8 result on both targets, without relying on the incorrect FMA behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100