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 65AE43858CDA; Tue, 10 Jan 2023 11:00:16 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65AE43858CDA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1673348416;
	bh=1ijeersrCEs8qk1KuYJM96jZegVVDETC34+MJAZ77V4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=y577EQW3iC389/vV67doGHMoLBOPkl9dz1IGQJRZUAohcYZzzizh3iiDWjaq0VpJX
	 Z/ZB7wWwJdryz68TYLmrAgrH5uAe9X8lcLPBsWE7uYnej4HgH0BofMaYQC2Oobu5X1
	 lvV4OC0D12GsQxVO136HUYSTT2Kp588QUkOYw7U8=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Tue, 10 Jan 2023 11:00:15 +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: <bug-107608-4-aZhkQQK25q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107608-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107608-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=3D107608

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #16)
> Created attachment 54224 [details]
> untested patch
>=20
> Perhaps this would work.  It solves the testcase, though I think we should
> probably audit the operators that don't use the generic
> range_operator_float::fold_range to make sure they're not doing anything
> silly.
>=20
> Note that we could add similar code whenever we drop to a NAN like
> const_binop does:
>=20
>       /* Don't constant fold this floating point operation if
> 	 both operands are not NaN but the result is NaN, and
> 	 flag_trapping_math.  Such operations should raise an
> 	 invalid operation exception.  */
>       if (flag_trapping_math
> 	  && MODE_HAS_NANS (mode)
> 	  && REAL_VALUE_ISNAN (result)
> 	  && !REAL_VALUE_ISNAN (d1)
> 	  && !REAL_VALUE_ISNAN (d2))
> 	return NULL_TREE;
>=20
> I avoided doing so because an frange of NAN does not count as a singleton=
 so
> it should never be propagated.  If this is a problem, I could add a simil=
ar
> tweak.
>=20
> What do y'all think?

I suppose it's a good workaround for now and consistent with what CCP
would end up doing.  Ideally we wouldn't restrict lattice propagation
so we can perform simplification of uses (esp. in conditionals) but
just prevent folding the actual computation that causes the overflow
(thus catch it at propagation stage).  As you say how ranger works doesn't
easily allow that, unfortunately.=