From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 537DC387416B; Fri, 16 Dec 2022 13:32:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 537DC387416B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671197561; bh=2fOFqtoywSRka8z4bf0LC9yweeXfFZ9b3UIq0PlmvlE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Wfyq5vH0gtrcdm9ZS43xSl2gqpgOkZ0eEP3YjmokY1PqFPnGH9IA6FNjLZMLUIvVF Z00IC/pHgXXyXZn2tXq0kdTdH45Dk/dHLwczTzar463NTe4Y2a7j0ygLQ6vN3tKwo4 Ik9+yWJl4L6alCQmHNnqNgc9ErWwfn6X4Atmld5I= From: "rguenth 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:32:40 +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: rguenth 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 #11 from Richard Biener --- (In reply to Jakub Jelinek from comment #10) > Some extra food for thought: > void bar (void); >=20 > 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 ou= t, > 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 > raise 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 ei= ther > replace the comparison(s) of z with some dummy (asm?) use of z, or keep t= he > comparisons but say turn the bar () call into __builtin_unreachable () or > __builtin_trap () and make sure we don't optimize away the former later? >=20 > The reason I want to show this is mainly that even when the actual operat= ion > (comparisons here) we'd like to fold into constant are known not to raise > any exceptions (and we should use frange info to find that out), it might= be > some intermediate calculation that might still raise exceptions. >=20 > 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 > singleton, but that still wouldn't cover comparisons. For the comparisons I think we need to split them out of the GIMPLE_COND (who do not have side-effects), so like with -fnon-call-exceptions do _3 =3D z < 6.0e+2; if (_3 !=3D 0) goto ; else goto ; then we can simplify the GIMPLE_CONDs just fine, we just need to keep the comparison in some way. For sNaN vs. qNaN I suppose we can use a tree predicate and go by the kind of definition we see - sNaNs can only appear via a few constrained operations (loads and init from a sNaN literal).=