On Fri, 11 Sep 2026, H.J. Lu wrote: > 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.
That sounds pragmatic, but IL is still wrong then. What is a minmal testcase to trigger the issue you are fixing with this patch? The PR is a bit hard to sort through. Richard. > > 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. > > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Abhinav Puri; (HRB 36809, AG Nuernberg)
