https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
pipcet at protonmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pipcet at protonmail dot com
--- Comment #11 from pipcet at protonmail dot com ---
I'm not sure, but if I understand this correctly, this optimization would break
Emacs. (I believe this is an Emacs bug, but the current consensus is not to
change it.)
The conservative GC used by Emacs does not currently scan jmp_buf structures
created on the heap. If such a jmp_buf were to hold the sole reference to a
live value, that would cause a crash, but right now, there seem to be no such
crashes.
This is because GCC-generated code appears to always save callee-saved
registers to the stack before modifying them, even in noreturn functions. Emacs
does not use -fexceptions-style exceptions; it uses its own sjlj mechanism. It
is currently possible to compile Emacs with -fno-exceptions, and ideally that
would remain true.
My understanding is that the longjmp variants are currently defined with
__attribute__ ((__nothrow__)) by glibc, through the confusingly-named __THROW
macro, so maybe this is an issue even without -fno-exceptions.
Emacs discussion at
https://lists.gnu.org/archive/html/emacs-devel/2025-11/msg00012.html ; it's
quite long, but the summary is:
1. The current Emacs GC does not scan jmp_bufs on the heap.
2. The proposed new Emacs GC does so
3. ... except on macos, where it was changed not to
4. crashes have been observed because jmp_bufs on the stack weren't scanned.
This was fixed, and no crashes have been observed because jmp_bufs on the heap
weren't scanned.
Note that even though GCC does not fully support macos, Emacs uses libgccjit on
that platform, so IIUC it's still an issue. However, it'd be great if Emacs
were to behave the same on all platforms.
