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 BCC643858006; Wed, 31 Jan 2024 08:53:56 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCC643858006
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1706691236;
	bh=rlF6OfmenZL6XGsJ9QBUodZ/FXpLzv8LPOSCwhf+c4k=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=LvC9TQAVBcqkKLy3M+IBJnng6kM3JCYOGUN1au6AWZ878BsBJ0F3RPVxJza3Ar4Xb
	 HTsiwOB6ys3CRYhSJfi2Ka9WqvOtZCfwAiwJMaW/QcikeWDq0CtabCdUaca/RDHKem
	 PyFmpWx6K5RTVu8FUWqj3VYYdUCf0mHAq9+C/YyE=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/113679] long long minus double with gcc -m32 produces
 different results than other compilers or gcc -m64
Date: Wed, 31 Jan 2024 08:53:56 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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-113679-4-TrzhHfhCVo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113679-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113679-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=3D113679

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, it is, that is how excess precision behaves.
Due to the cast applying just to l rather than l - d it returns 0.0 with
-fexcess-precision=3Dstandard, but if you change it to (double)(l - d) then=
 it
will return -2.0
at all optimization levels with -fexcess-precision=3Dstandard.=20
-fexcess-precision=3Dfast
behaves depending on what instructions are actually used and where the
conversions to float or double happen due to storing of expressions or
subexpressions into memory as documented.
If you don't like excess precision and have SSE2, you can use -msse2
-mfpmath=3Dsse.=