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 905633858D20; Thu, 10 Nov 2022 10:29:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 905633858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1668076153;
	bh=/7oG5dZkQpQNYJiWcmFNc3PmBrSJGe7dVBtTNhq27mI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=PpfycyuksGOPxwvBNZu0TZu94P7OAo9J1EaOOCumBEOc5YC2mr3rR/bYJV6Q4KE/5
	 0lLWTqNmPSFp8qBMN2ZPtyP/rpOykJBq6/FWJhzl6xaJd84n1zK+qUMa91s1+72NOA
	 g9zc4VHCDIfM2EYs8KsmvLHZZjdnCEECRTSvF8nc=
From: "jakub at gcc dot gnu.org" <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: Thu, 10 Nov 2022 10:29:13 +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: jakub at gcc dot gnu.org
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-mpxjyFApTc@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 #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, I was using:
double
foo (int x, int y)
{
  double r;
  if (x >=3D 0)
    return 0.0;
  switch (y)
    {
    case 1: r =3D 0.0; break;
    case 2: r =3D 1.0; break;
    default: r =3D 0.5; break;
    }
  return r * __builtin_pow (10.0, x);
}
as reduced testcase of what the Fortran testcase does, but I see there some
unrelated problem:
Folding statement: _2 =3D __builtin_pow (1.0e+1, _1);
Global Exported: _2 =3D [frange] double [0.0 (0x0.0p+0), +Inf] +NAN
The +NAN looks suspicious, shouldn't that be +-NAN ?
Of course once we handle POW builtins, if we are smart enough we should see
that it is 10.0 ** [INT_MIN, -1] and so [0.0, 1.0e-1] (plus some larger ulp
error because library functions aren't exactly 0.5ulp precise all the time)=
.=20
But when we don't know what __builtin_pow does (from frange perspective), I
don't see what
tells us that NAN with negative sign can't appear.=