Background
While cross-checking corvus's double-double log core across compilers, identical source produced different results at the same SIMD tier: GCC's default -ffp-contract=fast fused a mul into an adjacent add inside a compensated sequence, shifting the result 0.6 bits relative to MSVC (/fp:precise does not contract). Rebuilding GCC with -ffp-contract=off landed exactly on MSVC's number, confirming the cause. Nothing failed — contraction made that value slightly better — so a single-compiler test suite cannot notice. Full write-up: OldCrow/corvus PLAN.md, Decisions → "FP contraction off project-wide".
The hazard class: Kahan/Neumaier summation, TwoSum/Fast2Sum, and any fma(a, b, -a*b)-style exact-residual trick are exact identities whose proofs assume each IEEE operation is rounded as written. A compiler contraction landing inside one makes the "exact" correction term the error of an operation that never happened. libstats builds with the same fleet compilers (GCC default fast, AppleClang default on, MSVC none) and uses the same class of algorithms, so the exposure is plausible and the symptom is silence.
Ask
- Inventory compensated paths: Kahan/compensated summation, Welford-style variance updates with correction terms, log-sum-exp accumulations, any explicit error-free transformation.
- For each, check whether the TU is built with contraction enabled on any fleet compiler (GCC and AppleClang defaults contract; MSVC
/fp:precise does not).
- Decide policy. corvus's resolution:
-ffp-contract=off scoped PRIVATE to the affected targets, with fusion only ever requested explicitly (fma call/intrinsic), never inferred — measured cost ≤ ~8% on kernels, likely far less here. The alternative is documenting that cross-compiler reproducibility is not claimed.
- If any doc or test claims cross-compiler or cross-platform bit reproducibility, add a check that would have caught this (compare a compensated-path result across two compilers or against a no-contract reference build).
Sibling issue filed in libhmm; the corvus decision record has the compiler-by-compiler details.
Background
While cross-checking corvus's double-double log core across compilers, identical source produced different results at the same SIMD tier: GCC's default
-ffp-contract=fastfused a mul into an adjacent add inside a compensated sequence, shifting the result 0.6 bits relative to MSVC (/fp:precisedoes not contract). Rebuilding GCC with-ffp-contract=offlanded exactly on MSVC's number, confirming the cause. Nothing failed — contraction made that value slightly better — so a single-compiler test suite cannot notice. Full write-up: OldCrow/corvusPLAN.md, Decisions → "FP contraction off project-wide".The hazard class: Kahan/Neumaier summation, TwoSum/Fast2Sum, and any
fma(a, b, -a*b)-style exact-residual trick are exact identities whose proofs assume each IEEE operation is rounded as written. A compiler contraction landing inside one makes the "exact" correction term the error of an operation that never happened. libstats builds with the same fleet compilers (GCC defaultfast, AppleClang defaulton, MSVC none) and uses the same class of algorithms, so the exposure is plausible and the symptom is silence.Ask
/fp:precisedoes not).-ffp-contract=offscoped PRIVATE to the affected targets, with fusion only ever requested explicitly (fma call/intrinsic), never inferred — measured cost ≤ ~8% on kernels, likely far less here. The alternative is documenting that cross-compiler reproducibility is not claimed.Sibling issue filed in libhmm; the corvus decision record has the compiler-by-compiler details.