Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc: > On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov <amona...@ispras.ru> wrote: > > > > Hi Florian, > > > > On Thu, 14 Sep 2023, Alexander Monakov wrote: > > > > > > > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > > > > > > > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered > > > > several packages had test suite failures because x86-64 suddenly gained > > > > FMA support. I say “rediscovered” because these issues were already > > > > visible on other architectures with FMA. > > > > > > > > So far, our package/architecture maintainers had just disabled test > > > > suites or had built the package with -fp-contract=off because the > > > > failures did not reproduce on x86-64. I'm not sure if this is the right > > > > course of action. > > > > > > > > GCC contraction behavior is rather inconsistent. It does not contract x > > > > + x - x without -ffast-math, for example, although I believe it would be > > > > permissible under the rules that enable FMA contraction. This whole > > Is that really just x + x - x? We currently gate simplifying x - x to zero > on no-signed-zeros and round-to-nearest and have no special > handling for x + x - x. > > > > > thing looks suspiciously like a quick hack to get a performance > > > > improvement from FMA instructions (sorry). > > > > > > > > I know that GCC 14 has -fp-contract=standard. Would it make sense to > > > > switch the default to that? If it fixes those package test suites, it > > > > probably has an observable performance impact. 8-/ > > > > > > Note that with =standard FMA contraction is still allowed within an > > > expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'. > > > The difference between =fast and =standard is contraction across > > > statement boundaries. So I'd expect some test suite failures you speak of > > > to remain with =standard as opposed to =off. > > > > > > I think it's better to switch both C and C++ defaults to =standard, > > > matching Clang, but it needs a bit of leg work to avoid regressing > > > our own testsuite for targets that have FMA in the base ISA. > > > > > > (personally I'd be on board with switching to =off even) > > > > > > See https://gcc.gnu.org/PR106902 for a worked example where > > > -ffp-contract=fast > > > caused a correctness issue in a widely used FOSS image processing > > > application > > > that was quite hard to debug. > > > > > > Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we > > > make the change, so SPEC scores won't be affected. > > > > Is this the sort of information you were looking for? > > > > If you're joining the Cauldron and could poll people about changing the > > default, > > I feel that could be helpful. > > > > One of the tricky aspects is what to do under -std=cNN, which implies > > -ffp-contract=off; "upgrading" it to =standard would introduce FMAs. > > > > Also, I'm a bit unsure what you were implying here: > > > > > I know that GCC 14 has -fp-contract=standard. Would it make sense to > > > switch the default to that? If it fixes those package test suites, it > > > probably has an observable performance impact. 8-/ > > > > The "correctness trumps performance" principle still applies, and > > -ffp-contract=fast (the current default outside of -std=cNN) is > > known to cause correctness issues and violates the C language standard. > > And -ffast[-and-loose]-math for is not going away. > > I think that changing the default to =standard without -ffast-math is > reasonable. > IIRC the standard allows such default if it's indicated, so it doesn't require > =off anywhere.
The C standard requires a pragma to turn control it on and off, which GCC does not support. The default is then implementation defined. Martin
