From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id AFD3C3858C74; Thu, 29 Sep 2022 13:39:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFD3C3858C74
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1664458761;
	bh=5t29GNiLVN6JjoShHemOKetRc/UKNGrEAvnDimYB0EI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=neltX0Kz+MPhXKGCpoUKnLpb96K3gU8cgSmSrGy1gGn7kaxC3+RYyzyT2zSVu4ZzG
	 U10pV65Li9Rt185MNI/MIuBHTMR+IJXH15GJ+V+Ib6zrBbNj+UQY5grBXeJh0mEWBQ
	 EWfVCAtB/f6iWTpmiQVxlRzyDMCSpEy3aIEb0Ub8=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106902] [11/12/13 Regression] Program compiled with -O3
 -mfma produces different result
Date: Thu, 29 Sep 2022 13:39:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106902-4-Fe26q8bv0r@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106902-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106902-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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=3D106902
>=20
> --- 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
>=20
> Yes, but...
>=20
> >  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 =3DON and omit them for
> > =3DFAST.
>=20
> this will also prevent reassociation across statements too. Doing FMA
> contraction in the frontends via a match.pd rule doesn't have this drawba=
ck.

True - but does that catch the cases people are interested and are
allowed by the FP contraction rules?  I'm thinking of

 x =3D 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=3Don
only makes sense in absence of any other -ffast-math flags?=