From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C9B2E385800D; Mon, 19 Sep 2022 08:14:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C9B2E385800D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663575293; bh=iqWpBQgPxWMKyo4FU9cUyvDClY1Kk4Xc1uVtQMWuBio=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C0/GWNCZjYMDhlb//MplhvyQyDtkVzurwJc/bbKzi7ONNocIkhqtKbfBJhElKKf4f QA8AFqfyuX+/aCPNw7iPWVwrQ54CQ7W+jq0k0ZzqFANVR7kplOSfWHji8CCF209zTo OcdrbP2o4tbJ3VLZ0fV9RWYb1MxDnEprmEKirJ6c= From: "amonakov at gcc dot 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: Mon, 19 Sep 2022 08:14: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: RESOLVED X-Bugzilla-Resolution: INVALID 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106902 --- Comment #13 from Alexander Monakov --- (In reply to Richard Biener from comment #12) > > Isn't it easy now to implement -ffp-contract=3Don by a GENERIC-only mat= ch.pd > > rule? >=20 > You mean in the frontend only for -ffp-contract=3Don? Yes.=20 > Maybe, I suppose FE > specific folding would also work in that case. One would also need to re= ad > the fine prints in the language standards again as to whether FP contract= ion > allows to form FMA for >=20 > double tem =3D a * b; > double res =3D tem + c; >=20 > 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=3Dfast vs. -ffp-contract=3Don). 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, wh= ich is then used in subsequent iterations of the loop).=