On Fri, Aug 28, 2026 at 12:57 AM Oleg Tolmatcev <[email protected]> wrote: > > Targets that cannot realign the stack cap their stack alignment and rely > on the middle end to align over-aligned stack objects inside their slots. > Win64 SEH caps MAX_STACK_ALIGNMENT at 128 bits; aarch64 does not define > MAX_STACK_ALIGNMENT at all and is capped at STACK_BOUNDARY, also 128. > > In several places the middle end does not do that alignment. A 256-bit > vector requires 32-byte alignment, its slot gets the capped 16 bytes, and > MEM_ALIGN is set to 32 anyway. x86 selects vmovaps from MEM_ALIGN and
The easiest way is to use vmovups on stack if MEM_ALIGN > MAX_STACK_ALIGNMENT. > faults on the under-aligned slot (PR54412, MSYS2/MINGW-packages#1209). > There is an even bigger problem. Even with MEM_ALIGN and the slot's > alignment consistent, an escaped pointer loses the information about the > alignment cap: GCC assumes the object's natural alignment and uses an > aligned access on an under-aligned object, which faults on x86. >
