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.
next prev 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: linkBe 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).