GNU bug report logs -
#29040
emacs-26 crash due to misaligned longjmp buffer in 64-bit MSYS2/MinGW-W64 build
Previous Next
Reported by: Richard Copley <rcopley <at> gmail.com>
Date: Sat, 28 Oct 2017 13:42:02 UTC
Severity: normal
Tags: fixed
Done: Richard Copley <rcopley <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #57 received at 29040 <at> debbugs.gnu.org (full text, mbox):
> Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 2 Nov 2017 13:35:16 -0700
>
> Yes, we can stop using alignas entirely, since it doesn't work the way I
> expected. I thought that it could only increase alignment, and that it
> was a no-op if it specified a decreased alignment: this is how
> __attribute__ ((aligned (8))) works. However, I now see that C11 says
> that a compiler is supposed to report an error if alignas specifies a
> decreased alignment. So I installed the attached patch to stop using
> alignas.
Thanks, but I think the resulting code is confusing. E.g.:
static struct thread_state GCALIGNED main_thread;
This looks like we ask main_thread to be 8-byte aligned, which would
bring back the problems we had before. Requiring readers to read the
C Standard is not a good thing.
Can we come up with a clearer code, please?
> * Remove my_endbss_static in lastfile.c, since we no longer need to
> worry about the Alpha MSVC linker.
I don't know anything about that code, and I don't think anyone does.
Who will tell us that the comment is still accurate?
> * Remove the the _MSC_VER-specific code in lisp.h's definitions of
> ENUM_BF and DEFUN and in regex.c's definition of re_char and const_re_char.
I don't think ENUM_BF is only for MSVC. The condition there mentions
other compilers.
Anything that is conditioned by _MSC_VER can go.
This bug report was last modified 7 years and 208 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.