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 CFC503858D39; Thu, 29 Jun 2023 08:31:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CFC503858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688027474;
	bh=LVYUUGzRHwZ5+cCLsA6XVJHEC5eVEq7DsG+BOkIBGLA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=k0uxk0Vu56BUGhHp/2pRaZPE7tgGnuo/r4OCJsVT224j1UAJMijvosarDtycZoAYO
	 o0kY5LuVvSX71AaTDseahc/KLIxlVpI/TRkAJgsGR81qFEOd7Uc/2IUpV3uta0shiX
	 xqwoQGk7vtgv1CYnPh7I/kjUeKDP+5v0uII5O+e4=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/110477] -fexcess-precision=standard not applied
 consistently
Date: Thu, 29 Jun 2023 08:31:13 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.1.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110477-4-uwWXmmWFgA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110477-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110477-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=3D110477

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Peter Dimov from comment #1)
> Looks like a duplicate of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108742 and is fixed by cas=
ting
> the rhs to (float),

Yes, with -fexcess-precision=3Dstandard removal of excess precision only oc=
curs
when assigning to an lvalue or with an explicit cast, not for the equality
comparison.  An even simpler version is:

double f =3D 2.1;
assert( f =3D=3D 2.1 ); // fails

The value f has no excess precision bits, but the literal 2.1 is evaluated =
as
an 80-bit float. The comparison promotes f to the type of the rhs, but it's
lost its excess precision, so we're effectively doing (double)2.1L =3D=3D 2=
.1L and
that's false.

> but any ordinary programmer would be baffled.

Yes, very much so.


(In reply to Peter Dimov from comment #3)
> That's true, but the normal expectation of anyone using
> -fexcess-precision=3Dstandard would be for it to apply consistently every=
where
> (that is, as if FLT_EVAL_METHOD is 0.)
>=20
> Of course given that FLT_EVAL_METHOD is in a header, so unaffected by -f
> options, it's not clear what can be done here.

I think the rationale is that without -fexcess-precision=3Dstandard we do n=
ot
correctly respect FLT_EVAL_METHOD, so its value doesn't matter. With
-fexcess-precision=3Dstandard we do respect it ... with confusing consequen=
ces.

The solution is to kill i387 ;-)

-m32 -mfpmath=3Dsse gives more sensible results.=