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 D83EF3858C52; Fri,  3 Feb 2023 09:23:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D83EF3858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675416184;
	bh=83DnC0u2tavs+f4JVX0JSxUtwc/FR5mgC/T83aiNvYA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cMZtfk8v7EcsAfQlRCP+YLFZ6Ju7PN/bavYpkiLf1TcOENFJfTzdwf3OIgTRFEskr
	 Qkhd7bBghIZxlgw0tfFAMOpQZh+o3ZuHZN7MEnFnFolTpJipCdkbhQExvinkpbdzYB
	 I8NWpOfyrVk7v6YFFlplSFFEfx9IqH4T7oyCb3AQ=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/106805] [13 Regression] Undue optimisation of
 floating-point comparisons
Date: Fri, 03 Feb 2023 09:23:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 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: 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-106805-4-o0sYCK31kh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106805-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106805-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=3D106805

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, the current state is that this is now optimized away by dom2 using fran=
ge,
like in PR107608 (which is closed with a workaround), but in this case the =
NaN
vs. 1.0
or NaN vs. Inf >=3D and <=3D comparisons get a singleton integral range whi=
ch dom2
then optimizes out.
GCC 12 optimizes it out currently even earlier because #c5 change isn't
backported there yet, but otherwise wouldn't suffer from the frange issue a=
nd
would be miscompiled only during expansion.

I'd say for now if you want such a function to raise exceptions even with
constant arguments, don't make it inline and add noipa attribute to it inst=
ead.
 That case I think has been fixed on the trunk already.=