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 EE4E43857838; Tue,  7 Mar 2023 12:23:55 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE4E43857838
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678191835;
	bh=8JospHo0+/NLPnzsmam39Hg/BBjx5jorRBFIfbR4QKg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vW/9TpoSqbKB0trx3W9ufNNbrc7b42HRx3ovORaiKlRXVdJJtI7HXsZYbRO1xeAuo
	 mqxwPQAPfNPDu6JjzyE3i7Pk+vA7RN6GkfS09MG6hDA1c/NbYx3eBSafGTLo6jK79s
	 Exx4JCeKNfCi2CxkGuupOPx3Nsm9D9ydFU4mENjU=
From: "rguenth 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: Tue, 07 Mar 2023 12:23:55 +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: 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-109008-4-Iwpgh8lvFm@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 #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 54599 [details]
> gcc13-pr109008-wip.patch
>=20
> I have now this WIP but it doesn't work correctly yet, need to debug it n=
ow,
> just finished writing it and making it compile.
> Note, after the binary search it is still unfinished, I'd like to then
> adjust it one bit at a time to narrow it further.  But before working on
> that it needs to work correctly.

Looks nicer and more precise (even though the iterating function is ugly
and you also suffer from the lack of copying of alternate range state,
but using .union () is a way out here I guess ;)).

Can we ignore -frounding-math here?  The way you structured the tests
rely on doing the "correct" rounding?  Or does fold_range already
compensate for -frounding-math?=