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.
