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 30F263858CDB; Thu,  9 Mar 2023 11:06:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 30F263858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678359968;
	bh=fz0gqMVEdaEdydR2QRg9xJ5CocbD6QwQ8FHBx/RT+Dk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=XmWyjK1yky/QwNxqF0wTBfOfx3o4iK2Db4ZS9VKV/YXnG+OAlc5yPGEPmvQX9F+Mk
	 W0xo/oxKpiq527C/R/LA23/xPFYc2RNqBCSU6O3scT3HHbrAUE42uCXuvT+oVOTAt5
	 ooGgR9lpWV7K5F/4CrmJZB2av8uI8eZK6C1gcVCA=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109008] [13 Regression] Wrong code in scipy
 package since r13-3926-gd4c2f1d376da6f
Date: Thu, 09 Mar 2023 11:06:07 +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: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
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-109008-4-2FMWSCSWd1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109008-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109008-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=3D109008

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, regarding the behavior around DBL_MAX or -DBL_MAX, consider say:
__attribute__((noipa)) double
foo (double eps)
{
  double d =3D __DBL_MAX__ + eps;
  if (d =3D=3D __DBL_MAX__)
    return eps;
  return 0.0;
}
The exact range (tested with just trying to call the function with appropri=
ate
constants) is
[-0x0.fffffffffffff8p+970, 0x0.fffffffffffff8p+970], the function for those
boundary
values still returns that value, while for nextafter of the former towards =
-inf
(-0x0.8p+971) or nextafter of the latter towards +inf (0x0.8p+971) it alrea=
dy
returns 0.

GCC trunk before r13-6549 would compute obviously incorrectly
[frange] double [0.0 (0x0.0p+0), 0.0 (0x0.0p+0)]
and miscompile it.
r13-6549 computes
[frange] double
[-1.9958403095347198116563727130368385660674512604354575415e+292 (-0x0.8p+9=
72),
+Inf]
which is conservatively correct, but especially the +Inf side way too large.
With an untested patch I'm going to attach momentarily we get instead
[frange] double
[-1.9958403095347198116563727130368385660674512604354575415e+292 (-0x0.8p+9=
72),
1.9958403095347198116563727130368385660674512604354575415e+292 (
0x0.8p+972)], which is still wider than needed, but at least finite.=