From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A21CC383EB1D; Fri, 16 Dec 2022 13:20:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A21CC383EB1D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671196827; bh=0yxGsDUZEMGwkUmRpLrIQJxKLXB/BMPq58ZPjTmmtuU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Dq0+9lRVTDkiz89t/sOnuDvMkskptDSiQLjOD2i5MldyVYKQQ1nX4l6q+sS5JnW2F W9ePmS87SVAYZOu9jelYb3mUUxzjMCbLesxRMhA/EQNsEdd4zmDhsFl+SnLNTnPTE+ khjSaATiZ8OHo368K4PEf6jeH8DYmtWPDE8h5xlY= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c Date: Fri, 16 Dec 2022 13:20:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 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=3D107608 --- Comment #10 from Jakub Jelinek --- Some extra food for thought: void bar (void); void foo (double x) { if (x >=3D -16.0 && x <=3D 16.0) { double y =3D x + 32.0; double z =3D y * 42.5; if (z < 600.0 || z > 3000.0) bar (); } } with the usual default -O2 aka -O2 -ftrapping-math. frange can correctly prove that bar () will be never called and with -O2 -fno-trapping-math it is perfectly fine to optimize the whole function out,= z is known to be [680., 2040.] and not NaN. Now, even the comparisons aren't strictly needed, comparisons trap only on = NaNs (< and > are not quiet, so any kind of them, but after all, frange doesn't track sNaNs vs. qNaNs) and we know z is not NaN. But x comparisons can rai= se invalid on NaNs (both qNaN and sNaN), the addition is known not to raise invalid (x is not NaN), nor overflow (limited range), not sure right now if= it can raise underflow or inexact, but at least the latter quite possibly. The multiplication I'm quite sure can raise inexact though, so I think we need to keep everything until the z =3D computation, and eith= er replace the comparison(s) of z with some dummy (asm?) use of z, or keep the comparisons but say turn the bar () call into __builtin_unreachable () or __builtin_trap () and make sure we don't optimize away the former later? The reason I want to show this is mainly that even when the actual operation (comparisons here) we'd like to fold into constant are known not to raise a= ny exceptions (and we should use frange info to find that out), it might be so= me intermediate calculation that might still raise exceptions. I was considering to do some hack at least in my Fedora test mass rebuilds = this month like for flag_trapping_math pretend no floating point range is single= ton, but that still wouldn't cover comparisons.=