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 5E48E385842A; Tue,  8 Nov 2022 15:53:47 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E48E385842A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1667922827;
	bh=WMjHtPOxOFuICl15IlyMi9A8Tt97nPizGgvh+Gm90ko=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=mltDvfNr53YG7UFi3hDiSdCAXqKToGD0Ckui65FDyoGG9iSzP/29WlhhmVtg0y6W1
	 Q3yQjIN2LHUKZbRltxsCchd2y032grSgcCQ5SkwNbMstjKZbM5MH6cBkfEa1s4YrS9
	 oWFoVeyScKULY60aIWbQ1EFcYr/l72ca0at3A/2k=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107569] [13 Regression] Failure to optimize
 std::isfinite since r13-3596
Date: Tue, 08 Nov 2022 15:53:46 +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
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
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-107569-4-Z9CM5u2BcM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107569-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107569-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=3D107569

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #6)
> __builtin_isfinite (x) is implemented as
> ~UNGT_EXPR<ABS_EXPR<x>, DBL_MAX>.
> So, if we have:
>   _3 =3D ABS_EXPR <x_2(D)>;
>   _4 =3D _3 u> 1.79769313486231570814527423731704356798070567525844996599=
e+308;
>   _5 =3D ~_4;
>   return _5;
> for assume function, we should start with [1,1] assumption on _5, that
> implies
> _4 [0,0], and from UNGT_EXPR being false, we should derive that
> _3 is [-inf,
> 1.79769313486231570814527423731704356798070567525844996599e+308] and not =
NaN
> (if any operand is NaN, UNGT_EXPR is true, it stands for unordered or
> greater).
> And from _3 being [-inf,
> 1.79769313486231570814527423731704356798070567525844996599e+308] not NaN
> we should derive that x_2(D) is
> [-1.79769313486231570814527423731704356798070567525844996599e+308,
> 1.79769313486231570814527423731704356798070567525844996599e+308] not NaN
> (aka finite number).

oh, we're talking different cases.  lets se.

x_2(D) -> [frange] double
[-1.79769313486231570814527423731704356798070567525844996599e+308
(-0x0.fffffffffffff8p+1024),
1.79769313486231570814527423731704356798070567525844996599e+308
(0x0.fffffffffffff8p+1024)] +-NAN
_3 -> [frange] double [-Inf,
1.79769313486231570814527423731704356798070567525844996599e+308
(0x0.fffffffffffff8p+1024)]
_4 -> [irange] bool [0, 0] NONZERO 0x0
_5 -> [irange] bool [1, 1]

so we arent getting that x_2 is not NaN.
THat would be a failing of foperator_abs::op1_range to not add the nans if =
the
LHS has no NaNs then?  it looks like the range is correct, but non the NaN.

So I guess there are 2 different issues in this PR.  I was orignally lookin=
g at
the second one.=