https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Richard Biener from comment #3) > (In reply to Eric Botcazou from comment #2) > > > Maybe Eric can clarify which type kinds in Ada can have TYPE_USER_ALIGN > > > and > > > _not_ a TYPE_MAIN_VARIANT without. > > > > All of them, TYPE_USER_ALIGN is supposed to be orthogonal to type variants. > > How do you get at the alignment the type would have when the user didn't > specify it? That's what the call ABI is supposed to look at. > > /* 1 if the alignment for this type was requested by "aligned" attribute, > 0 if it is the default for this type. */ > #define TYPE_USER_ALIGN(NODE) (TYPE_CHECK (NODE)->base.u.bits.user_align) > > so what's the "default" alignment? What stor-layout.cc sets it to. For scalar types on targets which don't define ROUND_TYPE_ALIGN, I think it is usually (see stor-layout.cc (finalize_type_size)) GET_MODE_ALIGNMENT (TYPE_MODE (type)), for vector types targetm.vector_alignment (type). AGGREGATE_TYPE_Ps should have their specified user alignment honored. The reason why we shouldn't take user alignment into account for ABI argument and return value passing is e.g. because useless_type_conversion_p doesn't really take that user alignment on the scalar types into account. E.g. integer type conversions are considered equal if they have same mode, same signedness and same precision, scalar floats if they have same mode, pointers/references indeed same mode and same address space, vectors have some extra rules as well, but none of that takes into account the alignment. So, what exact type you get in the call vs. what exact type the callee expects might have different alignment, and it is the default alignment that should matter there (solely).
