From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 64D993858C27; Thu, 25 Nov 2021 19:40:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64D993858C27 From: "roger at nextmovesoftware dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above Date: Thu, 25 Nov 2021 19:40:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: roger at nextmovesoftware dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to short_desc cf_gcctarget 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 19:40:16 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103406 Roger Sayle changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|roger at nextmovesoftware dot com |unassigned at gcc d= ot gnu.org Summary|[12 Regression] gcc -O0 |gcc -O0 behaves differently |behaves differently on |on "DBL_MAX related |"DBL_MAX related |operations" than gcc -O1 |operations" than gcc -O1 |and above |and above | Target| |x86_64 --- Comment #13 from Roger Sayle --- The Inf - Inf =3D> 0.0 regression should now be fixed on mainline. Hmm. As hinted by Richard Beiner's investigation, the underlying problem is even more pervasive. It turns out that on x86/IA64 chips, floating point addition is not commutative, i.e. x+y is not the same as y+x, as demonstrat= ed by the test program below: #include const double pn =3D __builtin_nan(""); const double mn =3D -__builtin_nan(""); __attribute__ ((noinline, noclone)) double plus(double x, double y) { return x + y; } int main() { printf("%lf\n",plus(pn,mn)); printf("%lf\n",plus(mn,pn)); return 0; } Output: nan -nan Unfortunately, GCC assumes almost everywhere the FP addition is commutative and (as per comments #8 and #9) associative with negation/minus. This appe= ars to be target property, c.f. libgcc's _FP_CHOOSENAN, but could in theory be resolved by a -fstrict-math mode (that implies -ftrapping-math) that disabl= es commutativity (swapping of operands) throughout the compiler, including reload/fold-const etc., on affected Intel-like targets. Perhaps this PR is a duplicate now that the regression has been fixed?=