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 C0D863858C20; Fri, 20 Jan 2023 15:36:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C0D863858C20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1674228966;
	bh=vBDLXUZksnWn8DG7/EvpMwlmKClFXKRjLyvUHMYhyV8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=QnPRIEaus/4RcGTxISDo+DaMtXDjwxxpGG010hgA7FvtDRwBKOMB4ODRma70XOtFI
	 jjDQRFB41C5QRrj5RTb/RB6TxMDDPRRjSgnsXaaxmOoscXvjgMG2E8a/9CNnxgXw+m
	 1mBrnDHUxQPBS47fYckOa9rAA4IXB92taT19GDtk=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/108447] [13 Regression] glibc
 math/test-*-iseqsig failures
Date: Fri, 20 Jan 2023 15:36:06 +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, wrong-code
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-108447-4-5FV9hI8LAq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108447-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108447-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=3D108447

--- Comment #22 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Andrew Macleod from comment #19)
> > Created attachment 54313 [details]
> > better patch
> >=20
> > A more consistent approach.. rather than directly call relation_interse=
ct()
> > from multiple places, add the floating point fix to
> > value_relation::intersect and always go through that.
> >=20
> > This will cause the normal oracle and the path oracle to both make the
> > previous adjustment to intersect for floating point operations.   untes=
ted,
> > running tests now.
>=20
> I thought (unless somebody proves otherwise) that relation_intersect is
> actually just fine, the only thing that is incorrect (IMHO) for floating
> point with NaNs are the
> relation_union (VREL_L[TE], VREL_G[TE]) and relation_union (VREL_G[TE],
> VREL_L[TE])
> cases, because those return VREL_NE or VREL_VARYING even when those are
> actually
> LTGT_EXPR (aka ordered and not equal) or ORDERED_EXPR.
> So, if the callers of relation_union know whether it is a relation for
> floating point with NAN or integral/pointer/floating point fast math can't
> they just tweak those cases?

I have since evolved to something close to this.  I am moving all the
relation_intersect and relation_union calling locations to instead go throu=
gh
the existing value_relation class.  This stores a relation and 2 operands, =
and
isolates all the smarts for swapping operands and reversing relations as
needed.  (this is how the oracle internally handles it).   That class then
knows whether this is a floating point relation or not an can make adjustme=
nts
based on that, keeping it isolated to one place.

We wont have the actual floating point status of NAN and such, but we can at
least not get it wrong for this release in those cases.  THen decide how to=
 add
the required knowledge properly for the next release... maybe just adding a
couple of extra relations will be enough.=20

Patch forthcoming soon.=