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 B5EDA3858D38; Mon, 22 Apr 2024 21:50:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5EDA3858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713822651;
	bh=39ljfIS/VNdlIFt+WMe96H05Q7kp9ALY3A3fAAcZC2Q=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=C6W3cO6eLee6MDxqUiJDclRZ9yzHuCbCiQ14CCEt+RIZgsHkJgsnZB9HbPNUL2oXi
	 RpgwPCydeN84H4pbBAXdOtxqQS+mdRPQyvTvf3P1icdI4FynMUzqCFMx3nFXeLoepk
	 N9x5/l0hE7S8HC6twFq9gcg8Zy/hhuNhKOm2LPB0=
From: "vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast
 reduces the precision of floating-point constants and floating-point constant
 expressions
Date: Mon, 22 Apr 2024 21:50:51 +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: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vincent-gcc at vinc17 dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
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-114746-4-683sBvxBk7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114746-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114746-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=3D114746

--- Comment #6 from Vincent Lef=C3=A8vre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #5)
> FLT_EVAL_METHOD =3D 0 is on some hw like the pre-SSE2 ia32 extremely
> expensive, far more so than even the very expensive -ffloat-store.  That =
is
> certainly not a good default.  Plus I'm afraid it would suffer from double
> rounding, unless the floating point state is switched each time one needs=
 to
> perform some floating point instruction in a different precision.

I would think that in general, users would choose a FP type and stick to it.
However, there is the problem of libraries.

But I would be interested to know what would be the actual loss in practice,
for the use of such machines nowadays (if users want performance, there are
faster processors, with SSE2 support).=