[Bug middle-end/124697] Unnecessary stack realignment

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124697

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
> Am 31.03.2026 um 16:05 schrieb hjl.tools at gmail dot com <gcc-bugzilla@gcc.gnu.org>:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124697
> 
> --- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
> (In reply to rguenther@suse.de from comment #8)
>>> On Tue, 31 Mar 2026, hjl.tools at gmail dot com wrote:
>>> 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124697
>>> 
>>> --- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
>>> (In reply to H.J. Lu from comment #5)
>>>>> Yes.  This is wrong code.  My patch would have fixed it, doing
>>>>> effectively (but restricted to x86 at this point)
>>>>> 
>>>>> diff --git a/gcc/function.cc b/gcc/function.cc
>>>>> index 46c0d8b54c2..d44815afc16 100644
>>>>> --- a/gcc/function.cc
>>>>> +++ b/gcc/function.cc
>>>>> @@ -2840,7 +2840,7 @@ assign_parm_adjust_stack_rtl (tree parm, struct
>>>>> assign_parm_data_one *data)
>>>>>                                                 MEM_ALIGN (stack_parm))))
>>>>>          || (data->nominal_type
>>>>>              && TYPE_ALIGN (data->nominal_type) > MEM_ALIGN (stack_parm)
>>>>> -             && (MEM_ALIGN (stack_parm) < PREFERRED_STACK_BOUNDARY
>>>>> +             && (MEM_ALIGN (stack_parm) < BIGGEST_ALIGNMENT
>>>> 
>>>> What happens if BIGGEST_ALIGNMENT > PREFERRED_STACK_BOUNDARY and
>>>> BIGGEST_ALIGNMENT > MAX_SUPPORTED_STACK_ALIGNMENT.
>>> 
>>> Like this?
>>> 
>>> diff --git a/gcc/function.cc b/gcc/function.cc
>>> index 46c0d8b54c2..109821c16fc 100644
>>> --- a/gcc/function.cc
>>> +++ b/gcc/function.cc
>>> @@ -2840,7 +2840,8 @@ assign_parm_adjust_stack_rtl (tree parm, struct
>>> assign_parm_data_one *data)
>>>                   MEM_ALIGN (stack_parm))))
>>>     || (data->nominal_type
>>>         && TYPE_ALIGN (data->nominal_type) > MEM_ALIGN (stack_parm)
>>> -        && (MEM_ALIGN (stack_parm) < PREFERRED_STACK_BOUNDARY
>>> +        && ((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.
>>>         */
>> 
>> I had
>> 
>>  MEM_ALIGN (stack_parm)
>>  < SUPPORTS_STACK_ALIGNMENT ? MAX_SUPPORTED_STACK_ALIGNMENT :
>> PREFERRED_STACK_BOUNDARY
>> 
>> and SUPPORTS_STACK_ALIGNMENT && MAX_SUPPORTED_STACK_ALIGNMENT <
>> BIGGEST_ALIGNMENT would be a condition that does not make much
>> sense and thus would be a not allowed target configuration.
> 
> We don't align beyond BIGGEST_ALIGNMENT even if SUPPORTS_STACK_ALIGNMENT
> is true.

Then we’d still miscompile the address taken case?

> 
> --
> You are receiving this mail because:
> You are on the CC list for the bug.