all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





      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.