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

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 29 May 2020 21:01:39 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 41321@debbugs.gnu.org, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
> (2) has this comment:
> +/* Alignment needed for memory blocks that are allocated via malloc
> +   and that contain Lisp objects.  On typical hosts malloc already
> +   aligns sufficiently, but extra work is needed on oddball hosts
> +   where Emacs would crash if malloc returned a non-GCALIGNED pointer.  */
> 
> I can't make sense of that comment. It describes two problems that
> don't happen, and omits the problem that does happen.
> 1. malloc() % GCALIGNMENT != 0. Never happens, as far as I can tell.
> 2. A Lisp object requires greater alignment than malloc() gives it.
> IIRC, there was at least one RISC architecture whose specification
> supported atomic operations only on the first word in each
> 32-byte-aligned block, but that's such a rare case (and wasn't true
> for the silicon implementations, I seem to recall) that it seems silly
> to worry about it today.
> 
> I'm not saying it's the best solution, but I would prefer simply
> defining LISP_ALIGNMENT to be 8 to either patch.

I agree, but patch 2 basically does that, so I'm okay with saying "8"
in so many words.

Btw, can someone remind me why we started requiring non-default
alignment from Lisp objects?

Also, given the fact that in the crashing case the 2 32-bit parts of a
Lisp object were pushed onto the stack non-contiguously, will fixing
the alignment alone cause those Lisp objects to be marked?