[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #11)
> Can we move -ffp-contract=fast under the -ffast-math umbrella and default to
> -ffp-contract=on/off?

That's probably a question for the frontend maintainers.

> Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
> rule?

You mean in the frontend only for -ffp-contract=on?  Maybe, I suppose FE
specific folding would also work in that case.  One would also need to read
the fine prints in the language standards again as to whether FP contraction
allows to form FMA for

 double tem = a * b;
 double res = tem + c;

or across inlined function call boundaries which we'll happily do.

Of course for the testcase at hand it's all in
a single statement and no parens specify association (in case parens also
matter here, like in Fortran).  The fortran frontend adds PAREN_EXPRs
as association barriers which also would prevent FMAs to be formed.