public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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 10:26:23 +0000	[thread overview]
Message-ID: <bug-113679-4-VCSNWeBpqp@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113679-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And while SSE/SSE2 has instructions for performing arithmetics in IEEE754
single and double formats, x87 does not, everything is done in extended
precision (unless the FPU is configured to use smaller precision but then it
doesn't support the extended precision long double on the other side) and
conversions to IEEE754 single/double have to be done when storing the extended
precision registers into memory.
So, it is impossible to achieve the expected IEEE754 single and double
arithmetics behavior, one can get only something close to it (but with double
rounding problems) if all the temporaries are immediately stored into memory
and loaded from it again.
The -ffloat-store option does it to a limited extent (doesn't convert
everything though), but still, the performance is terrible.
C allows extended precision and specifies how to should behave, that is the
-fexcess-precision=standard model (e.g. enabled by default for
-std=c{99,11,...} options as opposed to -std=gnu..., then it is consistently
using the excess precision with some casts/assignments mandating rounding to
lower precisions, while -fexcess-precision=fast is what gcc has been
implementing before it has been introduced, excess precision is used there as
long as something is kept in the FPU registers and conversions are done when it
needs to be spilled to memory.

  parent reply	other threads:[~2024-01-31 10:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31  8:40 [Bug c/113679] New: " dilyan.palauzov at aegee dot org
2024-01-31  8:44 ` [Bug target/113679] " pinskia at gcc dot gnu.org
2024-01-31  8:45 ` dilyan.palauzov at aegee dot org
2024-01-31  8:52 ` pinskia at gcc dot gnu.org
2024-01-31  8:53 ` jakub at gcc dot gnu.org
2024-01-31  9:58 ` dilyan.palauzov at aegee dot org
2024-01-31 10:02 ` pinskia at gcc dot gnu.org
2024-01-31 10:26 ` jakub at gcc dot gnu.org [this message]
2024-01-31 14:32 ` dilyan.palauzov at aegee dot org
2024-01-31 14:35 ` jakub at gcc dot gnu.org
2024-01-31 14:38 ` jakub at gcc dot gnu.org
2024-01-31 15:53 ` jakub at gcc dot gnu.org
2024-02-07  5:55 ` egallager at gcc dot gnu.org
2024-02-10 14:32 ` dilyan.palauzov at aegee dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-113679-4-VCSNWeBpqp@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).