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 7C6233856970; Thu, 11 May 2023 17:32:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C6233856970
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683826372;
	bh=1ZzAC7Fr/T+MRPYDNVRKCWHuyqdJ1YRr4ljiWHUkWQ4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fBER6lMpeyw68Y1wdvLmgs/X+U1PCx2KfL317E/s9sZgPwJoPrFMHOWp2neP8EFGc
	 nX1Oi9M5BYtFA2hZG4RiFM0N7ejcLhyBcNTgdX8n79dmXsx87mqOMiTdx87Sutse6Y
	 n/oaCKR8kNPz/b0UACP5nc+g4gg0lL6DxYz88N84=
From: "amonakov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106902] [11/12/13/14 Regression] Program compiled with
 -O3 -mfma produces different result
Date: Thu, 11 May 2023 17:32:51 +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: amonakov at gcc dot gnu.org
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-sOPVGwJwN9@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 #20 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
I missed it the first time around, but placing PAREN_EXPR around the comple=
te
expression won't work: nothing will prevent GCC from duplicating evaluation=
s of
the sub-expressions, and then randomly forming FMAs like here. It would just
bury this class of bugs deeper.

Now that we are in stage1, can we make some kind of progress here? Is there=
 any
buy-in for:

1. Implementing fp-contract=3Don via GENERIC folding?
2. Defaulting to fp-contract=3Don instead of fp-contract=3Dfast under -std=
=3Dgnu*?
3. Enabling fp-contract=3Dfast under -ffast-math?=