Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill <jason at redhat dot com>]

On Thu, 24 Apr 2003 01:47:22 -0400, Geert Bosch <bosch at gnat dot com> wrote:

> On Wednesday, Apr 23, 2003, at 23:30 America/New_York, Jason Merrill wrote:

>> 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.
>
> No, this is not the case. Specifying an alignment for an object means
> "don't reduce".

I was referring to what dewar said here:

On Mon, 21 Apr 2003 17:35:51 -0400 (EDT), dewar at gnat dot com (Robert Dewar) wrote:

>   type A is ...
>
>   B : A;
>   for B'Alignment use 4;
>
>   Put_Line (Integer'Image (B'Alignment));
>
> This must output 4. Of course the compiler could still silently put
> B on a bigger alignment, since there would be no way to tell that it
> was doing this systematically, but this would be a poor implementation.

To me, this means that DECL_ALIGN for B must be exactly 4, whereas giving A
a TYPE_ALIGN of 4 would only mean that DECL_ALIGN for B must be at least 4.

This, I think, is also the distinction that kenner has been suggesting is a
reason to distinguish between TYPE_USER_ALIGN and DECL_USER_ALIGN.

> Of course the compiler should have a good reason to increase, but that's
> a quality of implementation issue. For example, a compiler might well
> align all 14-byte local objects of a 2-byte aligned type to 16 bytes and
> then take advantage of that stricter alignment in code generation.

This seems to conflict with what dewar is saying.

> Specifying an alignment for a type means "don't reduce" the alignment
> for any allocations of objects of this type and "don't assume increased"
> alignment for any objects accessed of this type.

I think everyone agrees about this.  The alignment for a type is a contract
between definitions and uses.

So, what exactly do we need to be able to express?

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.

It seems to me that the question people have been arguing about is what to
do about the distinction between 4 and 5.  I think that DECL_USER_ALIGN was
intended to mean 2, which logically extends to 4.

rth's patch of 2001-08-15 changed it to mean 5.

It makes sense to inherit DECL_USER_ALIGN from TYPE_USER_ALIGN if it means
4, but not if it means 5; that's why we're seeing the S/390 problem.

There would seem to be two ways to fix this:

A) Stop inheriting DECL_USER_ALIGN from TYPE_USER_ALIGN on VAR_DECLs.
B) Change DECL_USER_ALIGN to mean 4, and use DECL_PACKED to mean 5.

I'm partial to solution B.  Other opinions?

Jason