On Fri, 11 Sep 2026, Richard Biener wrote:
> On Fri, 11 Sep 2026, Oleg Tolmatcev wrote:
>
> > пт, 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).
>
> OK, so I think your fix is on the right track, I just do not like
> to restrict it by adding a new API. Note that I expected the
> second testcase to work already - we should be doing a
> copy of 'x' to a properly aligned stack slot and pass that
> to 'get', and the code doing that should handle runtime
> re-aligning already. Maybe it's still wrong in detail?
> It should be the code that's last touched by r16-8383-gcc33cf487524e7
> (assign_parm_adjust_stack_rtl).
Ah, I see HJ left in the < MAX_SUPPORTED_STACK_ALIGNMENT checks
that I said were bogus:
|| (data->nominal_type
&& TYPE_ALIGN (data->nominal_type) > MEM_ALIGN (stack_parm)
&& ((MEM_ALIGN (stack_parm)
< MIN (BIGGEST_ALIGNMENT,
MAX_SUPPORTED_STACK_ALIGNMENT))
/* If its address is taken, make a local copy whose
maximum alignment is MAX_SUPPORTED_STACK_ALIGNMENT.
*/
|| (TREE_ADDRESSABLE (parm)
&& (MEM_ALIGN (stack_parm)
< MAX_SUPPORTED_STACK_ALIGNMENT))))))
so this shoud be
MEM_ALIGN (stack_parm) < BIGGEST_ALIGNMENT
|| TREE_ADDRESSABLE (parm)
though the TREE_ADDRESSABLE case could be left as-is for the testcase
at hand (that's for the case the alignment escapes and thus can be
asserted by the user).
Richard.
>
> Richard.
>
> >
> > Oleg
> >
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
