https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124697
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- 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.
