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 1AB373858C62; Wed,  8 Mar 2023 09:29:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1AB373858C62
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678267769;
	bh=TbggFFlHvZJBqvtk4Ew3fAJEc8aLT44MG1t578h/PpA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Y4g7NnPSOTLrdlBoMTO8/luMvI/TAhe0ds2z8TAEX3NuFGKj77/nJXWQNfE1QgWgF
	 ecUclbi13arC0YMd/pxSw0zCohLcPbz1aAHLg7XVT1bMA8InzxBnQfG6S3sOSLfWmJ
	 sfrlavn6r0LxqnVbxLDFNVzpVEpGTwvtUJLBZ1Vo=
From: "aldyh 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: Wed, 08 Mar 2023 09:29:28 +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: aldyh 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-109008-4-0w3Yg9YRbZ@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 #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #21)
> So without messing with real.cc to try exposing 0.5ulp adjustments for GCC
> 13 I'd simply do something like the following:
>=20
> diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
> index ff42b95de4f..1ae68503664 100644
> --- a/gcc/range-op-float.cc
> +++ b/gcc/range-op-float.cc
> @@ -2214,7 +2214,26 @@ public:
>      range_op_handler minus (MINUS_EXPR, type);
>      if (!minus)
>        return false;
> -    return float_binary_op_range_finish (minus.fold_range (r, type, lhs,
> op2),
> +    /* The forward operation is
> +        lhs =3D r + op2
> +       where the result is +-0.5ulp of lhs before rounding.  For the
> +       reverse operation we need the lhs range before rounding, so
> +       conservatively use nextafter on it.
> +       ???  REAL_VALUE_TYPE could handle this more precisely if we
> +       make sure to not round the inputs for the format before the
> +       real_operation is carried out and when we can properly round
> +       towards +-Inf for the lower/upper bounds.  */
> +    frange wlhs (lhs);
> +    if (!lhs.known_isnan ())
> +      {
> +       REAL_VALUE_TYPE lhsl =3D lhs.lower_bound ();
> +       frange_nextafter (TYPE_MODE (type), lhsl, dconstninf);
> +       REAL_VALUE_TYPE lhsu =3D lhs.upper_bound ();
> +       frange_nextafter (TYPE_MODE (type), lhsu, dconstinf);
> +       wlhs.set (type, lhsl, lhsu);
> +       wlhs.union_ (lhs);  /* Copy NaN state.  */
> +      }
> +    return float_binary_op_range_finish (minus.fold_range (r, type, wlhs,
> op2),
>                                          r, type, lhs);
>    }
>    virtual bool op2_range (frange &r, tree type,

Could we abstract this into an inline function until this could be properly
implemented in real.cc?=