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
> 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.

Thanks.
Alexander