This is the mail archive of the
mailing list for the GCC project.
Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT
- From: Jason Merrill <jason at redhat dot com>
- To: Geert Bosch <bosch at gnat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner), gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>
- Date: Thu, 24 Apr 2003 18:16:28 +0100
- Subject: Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT
- References: <email@example.com><386D9560-7618-11D7-8766-00039344BF4A@gnat.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?).
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?