ср, 23 сент. 2026 г. в 11:21, Richard Biener <[email protected]>: > > On Wed, 16 Sep 2026, Oleg Tolmatcev wrote: > > > Targets that cannot guarantee arbitrary stack alignment cap stack slots at > > MAX_SUPPORTED_STACK_ALIGNMENT. Win64 SEH caps MAX_STACK_ALIGNMENT at 128 > > bits; aarch64 does not define MAX_STACK_ALIGNMENT and is capped at > > STACK_BOUNDARY, also 128 bits. assign_stack_local silently ignored any > > alignment beyond that cap. > > > > A 256-bit vector requires 32-byte alignment, but its slot could therefore > > receive only 16-byte alignment while later MEM attributes still claimed 32. > > x86 could select vmovaps from that MEM_ALIGN and fault on the under-aligned > > slot (PR54412, MSYS2/MINGW-packages#1209). An escaped pointer has the same > > problem even when the local move is unaligned, since its type still promises > > the callee a 32-byte-aligned object. > > > > Make assign_stack_local_1 honour an explicit alignment beyond the cap by > > reserving enough space and aligning an address inside it at run time, as > > assign_parm_setup_block already did for BLKmode parameters and > > expand_stack_vars does for locals. Base the extra space on the alignment > > guaranteed for VIRTUAL_STACK_VARS_REGNUM rather than on the maximum > > alignment > > supported by the backend, since the frame itself is not guaranteed to have > > the latter alignment on all targets. > > > > Let a new internal assign_stack_local_2 return the address before run-time > > alignment. Store it in the temp slot and realign the address on reuse, > > while > > avoiding splitting or combining over-aligned slots. > > > > Honour required temporary alignment at run time, but cap merely preferred > > alignment. Preserve zero-size behavior and the target's preferred stack > > boundary, and emit run-time alignment only during expansion to RTL. > > > > Use ASLK_REDUCE_ALIGN where less alignment is acceptable: LRA spill slots > > and > > the deliberately over-aligned SJLJ function context. > > > > Regtested on x86_64-pc-linux-gnu and, under QEMU, on > > aarch64-unknown-linux-gnu, with no new failures. > > Thanks a lot, this is OK for trunk. > > Thanks, > Richard.
Thanks a lot for the review. I don't have commit access by the way. Oleg
