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

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #20)
> I missed it the first time around, but placing PAREN_EXPR around the
> complete expression won't work: nothing will prevent GCC from duplicating
> evaluations of the sub-expressions, and then randomly forming FMAs like
> here. It would just bury this class of bugs deeper.

Hmm, true.

> Now that we are in stage1, can we make some kind of progress here? Is there
> any buy-in for:
> 
> 1. Implementing fp-contract=on via GENERIC folding?
> 2. Defaulting to fp-contract=on instead of fp-contract=fast under -std=gnu*?
> 3. Enabling fp-contract=fast under -ffast-math?

Sounds reasonable.  Though I wouldn't use GENERIC folding but instead
some folding-like code in c-family/ that for example would get invoked
by genericization or via the gimplification hook?  If we'd add GENERIC
folding in fold-const.cc or match.pd the chance is that it will pick up
FMAs "late".