Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill <jason at redhat dot com>]

On 22 Apr 2003 21:03:57 -0700, Alexandre Oliva <aoliva at redhat dot com> wrote:

> On Apr 22, 2003, kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner) wrote:
>
>> So the question is when to supress the an optional increase for
>> objects and I claim the only time should be if there is an alignment
>> specified *for a particular object*.
>
> I suppose we'll have to agree to disagree on this one.  I strongly
> dislike the idea that factoring out an alignment specification from an
> object definition to a typedef, adjusting the object definition to use
> the typedef, should have any effect in the way the assembly code
> emitted for that object definition.

Sorry to come into this so late.

If I understand correctly (Jakub, correct me if I'm wrong), the intent of
the *_USER_ALIGNMENT code was to suppress ABI layout rules which reduce the
alignment of some fields on, say, x86.

Thus, a field with DECL_USER_ALIGNMENT must have the specified alignment,
and no less.

However, it can still have more alignment.  If the type specifies more
alignment, the alignment of the field is rounded up to the alignment of the
type.

If you don't want that behavior, you must also specify DECL_PACKED.
DECL_USER_ALIGNMENT means "don't reduce", and DECL_PACKED means "don't
increase".

It sounds like some parts of the compiler are treating DECL_USER_ALIGNMENT
as meaning both of these, which was not the intent.  Where is this
happening?

It also sounds like in Ada, specifying an alignment for a type means "don't
reduce", but specifying it for an object means both "don't reduce" and
"don't increase".  It seems to me that the way to handle this is to set
DECL_PACKED on such objects.

Of course, currently DECL_PACKED is only meaningful on FIELD_DECLs;
apparently we need to extend it to VAR_DECLs as well.

Does this make sense to everyone?

Jason