On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote: > My understanding is that this is not a hardware bug and that it's > specified that rounding does not happen on the multiply "sub-part" in > `FNMSUB`, but rounding happens on the `FMUL` that generates some input > to it.
AFAIK the C standard does only say "A floating *expression* may be contracted". I.e: double r = a * b + c; may be compiled to use FMA because "a * b + c" is a floating point expression. But double t = a * b; double r = t + c; is not, because "a * b" and "t + c" are two separate floating point expressions. So a contraction across two functions is not allowed. We now have -ffp- contract=on (https://gcc.gnu.org/r14-2023) to only allow C-standard contractions. Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you are building GCC 14 snapshot). The default is "fast" (if no -std= option is used), which allows some contractions disallowed by the standard. But GCC is in C++ and I'm not sure if the C++ standard has the same definition for allowed contractions as C. > I can look into `-ffp-contract=off` as you both have recommended. > One question -- if we have concerns that the host compiler may not be > able to handle `attribute((noinline))` would we also be concerned that > this flag may not be supported? Only use it in BOOT_CFLAGS, i. e. 'make BOOT_CFLAGS="-O2 -g -ffp- contract=on"' (or "off" instead of "on"). In 3-stage bootstrapping it's only applied in stage 2 and 3, during which GCC is compiled by itself. > (Or is the severity of lack of support sufficiently different in the two > cases that this is fine -- i.e. not compile vs may trigger floating > point rounding inaccuracies?) It's possible that the test itself is flaky. Can you provide some detail about how it fails? -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
