> Am 28.08.2026 um 18:24 schrieb Oleg Tolmatcev <[email protected]>:
>
> пт, 28 авг. 2026 г. в 15:55, Richard Biener <[email protected]>:
>>
>>> On Thu, 27 Aug 2026, Oleg Tolmatcev 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
>>> 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.
>>>
>>> aarch64 does not crash only because its loads and stores do not fault on
>>> a misaligned address; the object is under-aligned there just the same.
>>>
>>> Add assign_stack_local_aligned, which preserves the requested alignment by
>>> overallocating a slot and aligning an address inside it, and use it
>>> wherever an object gets a stack slot of its own. This is what
>>> assign_parm_setup_block already did for BLKmode parameters and what
>>> expand_stack_vars does for locals. Such a slot has no fixed frame offset,
>>> so it cannot be reused as a temp slot.
>>
>> It seems to me that assign_stack_local itself guarantees alignment.
>> Why does it (or rather assign_stack_local_1 with kind == ASLK_RECORD_PAD)
>> not work?
>>
>> Richard.
>
> assign_stack_local_1 silently caps the the alignment at
> MAX_SUPPORTED_STACK_ALIGNMENT which for Win64 SEH is 16 bytes:
>
> /* Ignore alignment if it exceeds MAX_SUPPORTED_STACK_ALIGNMENT. */
> if (alignment_in_bits > MAX_SUPPORTED_STACK_ALIGNMENT)
> {
> alignment_in_bits = MAX_SUPPORTED_STACK_ALIGNMENT;
> alignment = MAX_SUPPORTED_STACK_ALIGNMENT / BITS_PER_UNIT;
> }
>
> kind == ASLK_RECORD_PAD means that that the padding will be recorded
> in a free list for later reuse. It has no influence on alignment and
> assign_stack_local_1 does not even look at it before capping the
> alignment.
I question whether this is correct then. When requesting a stack slot with a
specific alignment and not explicitly allowing a lesser alignment we should get
that alignment honored (or ICE). I don’t think a new API for this is sound.
Note I am not an expert on the history of this semantics.
Richard
>
> Oleg
