From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D1782385840E; Thu, 19 Jan 2023 10:16:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D1782385840E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674123395; bh=Cisy78SikpGCeab64ePuWW0JzI16IPvsX7k/rEWh3D0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KzivvVcnFfA3jOVlYD3SAuUp/BX1tlBIT07dGbS4XsvPMmpdE7Pth2J1jaYVAKZQf 6WhhyeN6/5sAyCOStqrBGK3TQh84uSA9oQbUCf87a1AGrP07J5B89YN7CQE8pBdkq1 AapRN0+SP0g2z6dN2lA7vTDzBvXmBmscuNy5+Dvc= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures Date: Thu, 19 Jan 2023 10:16:34 +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: 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108447 --- Comment #10 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #9) > (In reply to Jakub Jelinek from comment #4) > > I see fold_using_range::relation_fold_and_or > > which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and bec= ause > > of > > relation_union (relation1, relation2) =3D=3D VREL_VARYING fold it to 1. > > But for floating point comparisons, LE | GE is not always true, it is t= rue if > > neither operand is NAN, otherwise false. >=20 > Ah, it was the union not the intersect. So we need something here that > would avoid resolving this to 1 if maybe_isnan() is true for either source > operand. One possibility would be to separate integral/pointer and floating point relations, use VREL_FP_LE etc. (and have more of them to cover even the extra ones). Another would be based on whether it is a floating point relation or integral/pointer relation use different relation_{intersect,union}, or pass those functions a bool flag whether it is floating point or not (well, to be precise, if NANs aren't honored, we can treat even floating point compariso= ns as integral/pointer ones). If we keep VREL_LE etc. for both floating point with NAN and other relation= s, I'd think we should treat them as the floating point <=3D etc. comparisons = with their meaning for NANs operand if any. And then go through the intersect/u= nion tables and think about each case whether it holds even for NANs or not. I assume most of the cases would be the same. Say <=3D intersected with >=3D= is really =3D=3D. But e.g. <=3D unioned with >=3D is not VREL_VARYING (the qu= estion is what to return in that case though, VREL_LAST as some way to express VREL_UNKNOWN?). BTW, with the additions of VREL_PE*, the intersect/union tables grew quite a lot but contain 0 (aka VREL_VARYING) in those extra slots. Does it make se= nse to include VREL_PE* in those tables at all when it isn't really meaningful?=