Can the Same Floating-Point Code Produce Different Results on x86 and ARM64?

For reproducible results, compile without fast-math transformations and control FMA contraction. GCC and Clang commonly use options such as `-fno-fast-math` and `-ffp-contract=off`; MSVC has `/fp:strict`. Also keep the rounding mode consistent and use the same math libraries when calling functions such as `sin`, `cos`, or `sqrt`.

For especially strict cross-platform determinism, explicitly control the order of operations, avoid relying on excess intermediate precision, and consider fixed-point or integer arithmetic where practical. No compiler flag can make every numerical library or every unconstrained optimization produce identical results automatically.

Your example is a good demonstration of this. With ordinary double-precision multiplication, `a * b` rounds to exactly `1.0`, so adding `-1.0` produces `0`. With an FMA, or with an older x86 x87 unit using extended precision internally, the tiny difference near `1.0` can survive long enough to produce a small nonzero result instead.

Older x86 code could therefore differ because x87 used 80-bit intermediates, while SSE and ARM64 normally use 64-bit double-precision operations. This is less about the CPUs randomly disagreeing and more about different intermediate precision or operation sequences.

The CPU instructions themselves are generally deterministic, and modern x86 and ARM64 processors both support IEEE 754 floating-point arithmetic. If the compiler emits the same operations with the same rounding mode, the basic results should match.

However, C++ and compiler optimizations can change the operations that are emitted. In particular, a compiler may turn `a * b + c` into a fused multiply-add (FMA), which performs the multiplication and addition with only one rounding step. That can produce a different result from separately rounding `a * b` and then adding `c`.