пт, 11 сент. 2026 г. в 13:54, Richard Biener <[email protected]>:
>
> 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.
The minimal test case is
gcc/testsuite/gcc.target/i386/pr54412-m256-byval-param.c from the
testsuite patch of this series, compiled for x86_64-w64-mingw32 with
-O0 -mavx -S:
#include <immintrin.h>
void
foo (__m256 x)
{
(void) x;
}
The home slot of x is only 16-byte aligned, because
assign_stack_local_1 caps it at MAX_SUPPORTED_STACK_ALIGNMENT, which
is 128 bits on Windows SEH. But set_mem_attributes then raises its
MEM_ALIGN to the 256 bits of the type, so GCC uses vmovaps, which
faults if the slot does not happen to be 32-byte aligned.
Here is a minimal test case for an escaping pointer to a misaligned slot:
typedef float v8sf __attribute__ ((vector_size (32)));
__attribute__ ((noipa)) v8sf
get (const v8sf *p)
{
return *p;
}
v8sf
f (v8sf x)
{
return get (&x);
}
f stores x to its misaligned home slot and passes the address to get,
which loads it with vmovaps (%rax).
Oleg
