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

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

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

--- Comment #13 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> > 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?

Yes. 

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

In C contraction is allowed only within an expression (hence a difference
between -ffp-contract=fast vs. -ffp-contract=on).

The original testcase was in C++, I think C++ does not specify it, but
hopefully we'd aim to implement the same semantics as for C.

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

Please note that in this testcase GCC is breaking language semantics by
computing the same value in two different ways, and then using different
computed values in dependent computations. This could not have happened in the
abstract machine (there's a singular assignment in the original program, which
is then used in subsequent iterations of the loop).