From: Andrea Corallo <acorallo@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 72145@debbugs.gnu.org
Subject: bug#72145: rare Emacs screwups on x86 due to GCC bug 58416
Date: Thu, 18 Jul 2024 10:19:03 -0400 [thread overview]
Message-ID: <yp1msmeailk.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <e7c67465-1734-48c8-82bb-6b96eee4e167@cs.ucla.edu> (Paul Eggert's message of "Tue, 16 Jul 2024 16:26:33 -0700")
Paul Eggert <eggert@cs.ucla.edu> writes:
> While testing GNU Emacs built on Fedora 40 with gcc (GCC) 14.1.1
> 20240607 (Red Hat 14.1.1-5) with -m32 for x86 and configured
> --with-wide-int, I discovered that Emacs misbehaved in a hard-to-debug
> way due to GCC bug 58416. This bug causes GCC to generate wrong x86
> machine instructions when a C program accesses a union containing a
> 'double'.
>
> The bug I observed is that if you have something like this:
>
> union u { double d; long long int i; } u;
>
> then GCC sometimes generates x86 instructions that copy u.i by using
> fldl/fstpl instruction pairs to push the 64-bit quantity onto the 387
> floating point stack, and then pop the stack into another memory
> location. Unfortunately the fldl/fstpl trick fails in the unusual case
> when the bit pattern of u.i, when interpreted as a double, is a NaN,
> as that can cause the fldl/fstpl pair to store a different NaN with a
> different bit pattern, which means the destination integer disagrees
> with u.i.
>
> The bug is obscure, since the bug's presence depends on the GCC
> version, on the optimization options used, on the exact source code,
> and on the exact integer value at runtime (the value is typically
> copied correctly even when GCC has generated the incorrect machine
> code, since most long long int values don't alias with NaNs).
>
> In short the bug appears to be rare.
>
> Here are some possible courses of action:
>
> * Do nothing and hope x86 users won't run into this rare bug.
>
> * Have the GCC folks fix the bug. However, given that the bug has been
> reported for over a decade multiple times without a fix, it seems
> that fixing it is too difficult and/or too low priority for this
> aging platform. Also, even if the bug is fixed in future GCC the bug
> will still be present with people using older GCC.
>
> * Build with Clang or some other compiler instead. We should be
> encouraging GCC, though.
>
> * Rewrite Emacs to never use 'double' (or 'float' or 'long double')
> inside a union. This could be painful and hardly seems worthwhile.
>
> * When using GCC to build Emacs on x86, compile with safer options
> that make the bug impossible. The attached proposed patch does that,
> by telling GCC not to use the 387 stack. (This patch fixed the Emacs
> misbehavior in my experimental build.) The downside is that the
> resulting Emacs executables need SSE2, introduced for the Pentium 4
> in 2000 <https://en.wikipedia.org/wiki/SSE2>. Nowadays few users
> need to run Emacs on non-SSE2 x86, so this may be good enough. Also,
> the proposed patch gives the builder an option to compile Emacs
> without the safer options, for people who want to build for older
> Intel-compatible platforms and who don't mind an occasional wrong
> answer or crash.
Mmmh nice one :)
I asked GCC people if they have a suggestion on how to work around this
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416#c9>.
Thanks
Andrea
prev parent reply other threads:[~2024-07-18 14:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-16 23:26 bug#72145: rare Emacs screwups on x86 due to GCC bug 58416 Paul Eggert
2024-07-17 0:57 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-17 5:01 ` Paul Eggert
2024-07-17 21:56 ` Paul Eggert
2024-07-18 2:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-18 5:14 ` Eli Zaretskii
2024-07-18 3:22 ` Richard Stallman
2024-07-18 12:38 ` Paul Eggert
2024-07-18 15:19 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-19 21:31 ` Paul Eggert
2024-08-22 6:44 ` Paul Eggert
2024-07-18 14:19 ` Andrea Corallo [this message]
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=yp1msmeailk.fsf@fencepost.gnu.org \
--to=acorallo@gnu.org \
--cc=72145@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.