Soft-path FMA emulation: incorrect results under directed rounding modes (and two RNE-mode edge cases) #250
SolAstrius
started this conversation in
General
Replies: 1 comment
|
Related: |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Following up on a question raised in #246: does the odd-rounding soft FMA path in
fpu_lib.hstay correct under non-RNE rounding modes?I fuzzed the soft paths of
fpu_fma32andfpu_fma64_raw(builtin FMA compiled out) against two independent references — AArch64 hardware FMA and glibc's softfma/fmafon x86-64, which agree with each other on every counterexample. 5M exponent-biased random triples per mode:Four distinct failure classes, one minimal counterexample each (bit patterns;
soft= current soft path,ref= correctly rounded):RUP a=2f2cfc98 b=b45a0d25 c=c33f5ab8 → soft=c33f5ab7 ref=c33f5ab8RUP a=0e111f2c376c3b7c b=b09ab33b286b11f2 c=d1ae852da52f2f73 → soft=…2f72 ref=…2f73RNE a=1e492e4a5e074268 b=20636e8053091041 c=80043de497288d74 → soft=80043de41cd50b65 ref=…0b64mul = infmakesfpu_mul_error64computeinf − inf = NaN, which propagates to the result instead of ±inf:RNE a=69cdf850bf334cfd b=7ca8649ebebeef4e c=988d1e217a30a612 → soft=NaN ref=+infClasses 3 and 4 affect RNE too, i.e. any current build that takes the soft path (e.g. baseline x86-64 without
-mfma). fma32 is immune to overflow (the f64 product of two f32s can't overflow) and appears fully correct in RNE.Reproducers below.
fma_rm_test.cis standalone (replicates the soft paths verbatim);real_check.ccompiles against the actualsrc/util/fpu_lib.h(-I src/util) and confirms each counterexample above on the real code. Verified on macOS/AArch64 (clang,-O1 -ffp-model=strict) and Linux/x86-64 (gcc 15,-O1 -frounding-math).fma_rm_test.c— standalone fuzzerreal_check.c— counterexample checker against the real fpu_lib.hAll reactions