GNU bug report logs - #29040
emacs-26 crash due to misaligned longjmp buffer in 64-bit MSYS2/MinGW-W64 build

Previous Next

Full log

Message #39 received at 29040 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Wed, 1 Nov 2017 23:02:39 -0700

> +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t), GCALIGNMENT)
> +
> +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;

Three questions:

The Gnulib manual 
<https://www.gnu.org/software/gnulib/manual/html_node/stdalign_002eh.html> says, 
"Some compilers require the operand of _Alignas/alignas to be a single integer 
constant, not an expression: MSVC 7.0 through at least 10.0." (Also, 
<https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro> 
suggests that this issue may also occur with VS2013, though VS2015 should be OK 
since it supports alignas.) Are any of these older compilers of concern when 
building Emacs? If so, the above change won't work for them.

Why does the above code use 'alignof (max_align_t)' rather than 'alignof (struct 
thread_state)'? Doesn't the latter suffice?

C11 requires that a compiler must issue a diagnostic for a declaration like 
'struct thread_state alignas (8) foo;' if the alignment of plain 'struct state' 
is greater than 8. Can I take it from this bug report that the Microsoft 
compilers do not conform to that part of the standard? If so, we should add 
checks to verify this requirement where it is assumed elsewhere.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.