https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124697
--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to [email protected] from comment #10) > > Am 31.03.2026 um 16:05 schrieb hjl.tools at gmail dot com > > <[email protected]>: > > > > 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 [email protected] 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? > I have && ((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)))))) Address taken is handle by || (TREE_ADDRESSABLE (parm) && (MEM_ALIGN (stack_parm) < MAX_SUPPORTED_STACK_ALIGNMENT))))))
