https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 29 Sep 2022, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 > > --- Comment #17 from Alexander Monakov <amonakov at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #16) > > I do think that since the only way to > > preserve expression boundaries is by PAREN_EXPR > > Yes, but... > > > that the middle-end > > shouldn't care about FAST vs. ON (well, it cannot), but the language > > frontends need to ensure to emit PAREN_EXPRs for =ON and omit them for > > =FAST. > > this will also prevent reassociation across statements too. Doing FMA > contraction in the frontends via a match.pd rule doesn't have this drawback. True - but does that catch the cases people are interested and are allowed by the FP contraction rules? I'm thinking of x = a*b + c*d + e + f; with -fassociative-math we can form two FMAs here? Of course with strict IEEE compliance but allowed FP contraction we can only do FMA (a, b, c*d) + e + f, right? Does that mean -ffp-contract=on only makes sense in absence of any other -ffast-math flags?
