Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Zack Weinberg <zack at codesourcery dot com>]

Jason Merrill <jason at redhat dot com> writes:

> 1) For types, we want to be able to force a minimum alignment for
>   efficiency/correctness of access.
> 2) For fields, we want to be able to force a minimum alignment.
> 3) For fields, we want to be able to reduce alignment for packing efficiency.
> 4) For objects, we want to be able to force a minimum alignment.
> 5) For objects, we want to be able to force an exact alignment for building
>   up special sections (and for other reasons?).
>
> Anything else?
>
> 1 is handled by TYPE_ALIGN/TYPE_USER_ALIGN.
> 2 and 4/5 are handled by DECL_ALIGN/DECL_USER_ALIGN.
> 3 is handled by DECL_PACKED.

I'm leery of bringing DECL_PACKED into this -- the "packed" concept
has never really been nailed down as far as I know, and I worry that
it might bring in a whole 'nother set of conflicting assumptions from
the user community of __attribute__ ((packed)).

My suggestion would be that we rip out all the existing ALIGN stuff in
favor of two TYPE fields and two DECL fields named TYPE_MIN_ALIGN,
TYPE_MAX_ALIGN, DECL_MIN_ALIGN, and DECL_MAX_ALIGN.  The semantics are
that *_MIN_ALIGN is the minimum alignment to enforce for a type or
object, and *_MAX_ALIGN is the maximum alignment that can be assumed
for a type or object.  Then the front end gets to define whatever
rules it likes for setting these fields and inheriting them from types
to decls.

Note that, unless I'm even more confused than I think, normally
*_MIN_ALIGN >= *_MAX_ALIGN; possibly we want to give them different
names.

I think this covers all the cases but I could be wrong.

zw