all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: rcopley@gmail.com, 29040@debbugs.gnu.org
Subject: bug#29040: Emacs 25 hangs on windows arbitrarily during search of a unicode file
Date: Thu, 02 Nov 2017 17:50:01 +0200	[thread overview]
Message-ID: <83wp38r87q.fsf@gnu.org> (raw)
In-Reply-To: <e30d771e-aeeb-72cc-ad0b-e46f8629f2bb@cs.ucla.edu> (message from Paul Eggert on Wed, 1 Nov 2017 23:02:39 -0700)

> Cc: rcopley@gmail.com, 29040@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.

We've stopped supporting MSVC long ago.  Only GCC is supported for
building on MS-Windows.

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

No special reason, I just did the same as you did in aligning
pseudovectors, when we had a similar problem the last time.  Feel free
to change if you think it's better.

> 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.

Again, this is GCC, so what MS compilers do is not interesting.

The problem was caused by your changes in 015f0bb, which were for
OpenVMS:

  diff --git a/src/thread.c b/src/thread.c
  index c03cdda..6f12d79 100644
  --- a/src/thread.c
  +++ b/src/thread.c
  @@ -26,7 +26,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
   #include "coding.h"
   #include "syssignal.h"

  -static struct thread_state main_thread;
  +static struct thread_state alignas (GCALIGNMENT) main_thread;

   struct thread_state *current_thread = &main_thread;

This downgraded the alignment on 64-bit MS-Windows hosts, so I
upgraded it back.  If using alignas with an argument > 8 is
non-portable, then I guess we will have to make your OpenVMS fix
conditional on just that platform.  Or do you see a cleaner fix?





  parent reply	other threads:[~2017-11-02 15:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-28 13:40 bug#29040: emacs-26 crash due to misaligned longjmp buffer in 64-bit MSYS2/MinGW-W64 build Richard Copley
2017-10-28 13:55 ` Eli Zaretskii
2017-10-28 14:10 ` bug#29040: Trouble with misaligned jmp_buf in 64-bit MinGW-64 runtime, in Emacs 26 Richard Copley
2017-11-02  6:02 ` bug#29040: Emacs 25 hangs on windows arbitrarily during search of a unicode file Paul Eggert
2017-11-02  7:43   ` Richard Copley
2017-11-02 11:10     ` Noam Postavsky
2017-11-02 15:50   ` Eli Zaretskii [this message]
2017-11-02 20:35     ` Paul Eggert
2017-11-02 20:46       ` Eli Zaretskii
2017-11-03  5:03         ` Paul Eggert
2017-11-03  8:37           ` Eli Zaretskii
2017-11-03  8:48             ` Paul Eggert
2017-11-03  8:50           ` Eli Zaretskii
2017-11-03  9:25             ` Paul Eggert
2017-11-03 10:02               ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2017-10-19  1:18 C K Kashyap
2017-10-19  3:34 ` Eli Zaretskii
2017-10-28 11:05   ` Richard Copley
2017-10-28 11:31     ` Eli Zaretskii
2017-10-28 12:10       ` Richard Copley
2017-10-28 12:19         ` Eli Zaretskii
2017-10-28 12:25           ` Richard Copley
2017-10-28 12:31             ` Richard Copley
2017-10-28 12:49               ` Eli Zaretskii
2017-10-28 13:56                 ` bug#29040: " Richard Copley
2017-10-28 14:14                   ` Eli Zaretskii
2017-10-28 15:58                     ` Eli Zaretskii
2017-10-28 16:16                       ` Richard Copley
2017-10-28 16:41                         ` Eli Zaretskii
2017-10-29 18:10                           ` Richard Copley
2017-11-01 19:16                             ` Richard Copley
2017-11-02  7:39                               ` Richard Copley

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=83wp38r87q.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=29040@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=rcopley@gmail.com \
    /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.