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 5A9893858C53; Fri, 21 Jul 2023 08:11:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A9893858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689927084;
	bh=ji7rUdnIoYykV5OsmEyi0uXL1P0vFIcHhCk/rJ3rX4o=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=qA80HYhFVSbJncmICyjAFRpD7c43xXCkm8f6pzbWSJN3LdWdxFNTJXXgNzajXUEGo
	 hv9gpQDOr/ERuJK9ntH/Z64pQrSljKKYgzPq2gohznwI1pAAA/xUVyFbrKsMJXg5G3
	 CeNYtMPi9HSfMnS5XOURe3PrBoQbdv8tCs8ssxdE=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110755] [13/14 Regression] Wrong optimization
 of fabs on ppc64el at -O1
Date: Fri, 21 Jul 2023 08:11:24 +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.1.0
X-Bugzilla-Keywords: needs-bisection, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110755-4-VmRgZwIELu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110755-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110755-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=3D110755

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
A big hammer solution might be to treat flag_rounding_math in frange::set t=
he
same as
!HONOR_SIGNED_ZEROS, i.e. always extend [0, x] ranges to [-0, x] and [y, -0=
] to
[y, 0]
because we don't know what the rounding will do:
-  else if (!HONOR_SIGNED_ZEROS (m_type))
+  else if (!HONOR_SIGNED_ZEROS (m_type) || flag_rounding_math)
     {
       if (real_iszero (&m_max, 1))
         m_max.sign =3D 0;
       if (real_iszero (&m_min, 0))
         m_min.sign =3D 1;
     }
Though, such a change would affect even say operator_abs handling where we =
even
for flag_rounding_math are guaranteed the sign will be positive (unless
-fno-signed-zeros, in that case it is right we don't assume anything).
Or do it in range_operator::fold_range?  Or some other spot?
Generally, operations like neg, abs, comparisons should be fine, but +-*/ at
least in the fold_range direction probably need to do that.=