From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4B7DC3858C66; Mon, 22 Apr 2024 09:23:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B7DC3858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713777804; bh=jOTwqdFuN1mXqMWMtXolTD/ULcLvAkYVLNHDQvnX+Yk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GgWyMcRT2BL95fsFWsXRFCDgKqQrfZHmxvYm6zSSIiqzq8Dgu346L5AZyaPSPpNN4 igZKQiwWNvaecpzfFs2uxeb5It2Zl6mI7mdPrjFxsD0/A2aNj1d9ocHnqjWUQJqFev qWsQgnQpGOWTpT4Dppiu8dfZoq03mBCKS49nN2Uk= From: "vincent-gcc at vinc17 dot net" 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 09:23:22 +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: 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=3D114746 --- Comment #4 from Vincent Lef=C3=A8vre --- I actually find it more confusing the fact that constants are not evaluated= in extended precision while everything else is evaluated in extended precision. The real solution to avoid confusion would be to change the behavior so that FLT_EVAL_METHOD =3D 0 by default; if users see an effect on the performance (which may not be the case for applications that do not use floating-point types very much), they could still use an option to revert to FLT_EVAL_METH= OD =3D 2 (if SSE is not available), in which case they should be aware of the consequences and would no longer be confused by the results. But in addition to the confusion, there is the accuracy issue with the curr= ent behavior.=