bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Mon, 25 May 2020 11:28:46 +0000
> Cc: 41321@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> And I just noticed strings aren't aligned to LISP_ALIGNMENT on
> x86_64-pc-linux-gnu.
> 
> I think we're going to have to weaken the maybe_lisp_pointer check to
> check only for GC_ALIGNMENT.

I tend to agree.

Paul, why did we move to max_align_t as the alignment requirement?
AFAIU, GCC enlarged that recently to allow for _Float128 type (at
least on 32-bit hosts), but do we really need that?

Also, what does this mean for stack-based Lisp objects?  AFAIU, we
previously required 8-byte alignment on 32-bit hosts (and on
MS-Windows we jump through some hoops to guarantee that in callbacks
of Windows APIs and in thread functions that manipulate Lisp objects).
Does the use of max_align_t means that now stack-based Lisp objects
will need to have 16-byte alignment on 32-bit Windows?