Can the same floating-point code produce different results on x86 and ARM64?

The basic arithmetic instructions are normally deterministic when both platforms use IEEE 754 floating point with the same rounding mode. However, C++ and compiler optimizations can change the sequence of operations. In particular, a compiler may turn `a * b + c` into one fused multiply-add instruction. FMA rounds only once, while separate multiplication and addition round twice, so the results can differ even on the same CPU family.

For reproducible results, disable fast-math transformations and FMA contraction where necessary, use consistent compiler options, and control the floating-point environment. GCC and Clang commonly use options such as `-fno-fast-math` and `-ffp-contract=off`. Exact guarantees still depend on the language, compiler, libraries, and target settings.

The particular example is a good demonstration, although the difference is more about intermediate precision and operation selection than ARM versus x86 directly. With ordinary IEEE double operations, `a * b` rounds to approximately `1.0`, so the final result can be `0`. If the compiler emits an FMA, the exact product-plus-sum is `-2^-54`, which is a small nonzero value.

Older x86 code using the x87 floating-point unit could also keep intermediates in 80-bit precision, producing yet another result. SSE-based x86-64 code and typical ARM64 code generally use 64-bit intermediates, but optimization settings can still make the generated instructions differ.

The processor usually isn't arbitrarily giving a different answer: the compiler, instruction set, intermediate precision, rounding mode, and optimization level determine what actually runs. Two builds of the same source can therefore behave differently even on identical hardware. IEEE 754 standardizes the behavior of many basic operations, but it does not mean every C++ expression must be evaluated in exactly the same way.

Different results can also come from math-library functions such as `sin`, `cos`, or `exp`; their implementations and accuracy guarantees vary by platform. Reordering expressions can matter too, because floating-point arithmetic is not generally associative, commutative in every practical context, or distributive.

If bit-for-bit determinism matters—such as in a lockstep simulation—use carefully specified operations, fixed rounding behavior, deterministic math routines, and matching compiler settings. Many systems instead use fixed-point or integer arithmetic for the simulation state, or designate one machine as authoritative, because strict cross-platform floating-point reproducibility can be costly.