On Mon, Jul 7, 2025 at 11:08 PM H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Mon, Jul 7, 2025 at 11:08 PM Jason Merrill <ja...@redhat.com> wrote:
> >
> > On 7/1/25 5:36 PM, H.J. Lu wrote:
> > > On Tue, Jul 1, 2025 at 9:37 PM Jason Merrill <ja...@redhat.com> wrote:
> > >>
> > >> On 6/30/25 7:03 PM, H.J. Lu wrote:
> > >>> On Mon, Jun 30, 2025 at 10:36 PM Jason Merrill <ja...@redhat.com> wrote:
> > >>>>
> > >>>> On 6/28/25 7:00 AM, H.J. Lu wrote:
> > >>>>> Since a backend may ignore user type alignment for arguments passed on
> > >>>>> stack, check backend for argument alignment on stack when evaluating
> > >>>>> __alignof.
> > >>>>
> > >>>> I assume that's reflected in DECL_ALIGN, so could we just add 
> > >>>> PARM_DECL to
> > >>>
> > >>> No.  targetm.calls.function_arg_boundary may have special handling for 
> > >>> it.
> > >>
> > >> Why wouldn't we adjust DECL_ALIGN of the PARM_DECL to reflect the actual
> > >> alignment of the argument?  Are you saying it could be different from
> > >> one call to another?
> > >
> > > Function argument alignment is different from other places in memory if
> > > the main variant type alignment is different:
> >
> > Yes, I understand that function parameter alignment can be different
> > from other objects of that type.
> >
> > But since we have a PARM_DECL to represent that particular function
> > parameter, it seems natural to represent that difference in the
> > DECL_ALIGN of the PARM_DECL.  If you don't, its DECL_ALIGN is wrong.
> >

The parameter visible to the program does not need to share storage with
the parameter space used for parameter passing which can happen in
registers, or even partial in memory/registers or - as in this case - in
memory that is not aligned as the formal parameter is.

In such a case GCC arranges for local storage (with proper alignment)
that is populated from the argument storage (but it doesn't happen for the
case in question due to a bug IMO).

> __alignof returns TYPE_ALIGN, not DECL_ALIGN.  For PARM_DECL,
> TYPE_ALIGN may not be the same as DECL_ALIGN.

I don't think it's wise to try to "fix" this in the frontend.  A DECL_ALIGN
that is smaller than TYPE_ALIGN sounds bogus to me - while DECL_ALIGN
should always be the ultimate source of truth having a larger TYPE_ALIGN
just means the TYPE_ALIGN is wrong.  But the type is what the user
controls here, so we can't support the case in question (lower DECL_ALIGN).

Richard.

>
> --
> H.J.

Reply via email to