Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> So if you turn:
> 
> T i __attribute__((align(2)));
> T j __attribute__((align(2)));
> 
> into
> 
> typedef T T2 __attribute__((align(2)));
> T2 i, j;
> 
> you say we could get different code?  It sounds to me like they
> *should* be equivalent.  The compiler can't tell whether the user
> meant the alignment of a type is meant for composites only or for
> factoring of attributes in object declarations.

Yes, at least that's the intention in Ada. Setting an alignment for a type
specifies a minimum alignment for objects.

Consider the following

   type A is ....
   for A'Alignment use 4;

   B : A:

   Put_Line (Integer'Image (B'Alignment));

Ada semantics say that the value printed must be 4 or a multiple of 4.


  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.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jamie Lokier]

Robert Dewar wrote:
> Yes, at least that's the intention in Ada. Setting an alignment for a type
> specifies a minimum alignment for objects.
> 
>   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.

Must it output 4 even if A'Alignment is 8?

I think it should be an error to say "for B'Alignment use 4" in that
case, but I don't know Ada.

-- Jamie

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> 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*.

seems reasonable to me ...

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    The point is that you're saying it could increase the alignment of an
    object in spite of a user-specified alignment for its type.  You can't
    tell whether the alignment was defined for interface, space or
    performance, so a user-specified alignment for a type should be
    obeyed.

As has been discussed, "obeyed" means very different things for types
and objects.  For types, you must not treat the type as being more
aligned.  For objects, a more-aligned object is *also* less aligned, so
aligning an object more than that of its type is "obeying" the alignment
of the type.  And we know there are cases (such as minimum alignment on
S390) where you *must* increase the alignment of an object from that of
its type.

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*.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 22, 2003, kenner@vlsi1.ultra.nyu.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.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill]

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

> On Apr 22, 2003, kenner@vlsi1.ultra.nyu.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

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Geert Bosch]

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". 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.

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.

   -Geert

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill]

On Thu, 24 Apr 2003 01:47:22 -0400, Geert Bosch <bosch@gnat.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@gnat.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

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Zack Weinberg]

Jason Merrill <jason@redhat.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

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill]

On Thu, 24 Apr 2003 10:32:14 -0700, Zack Weinberg <zack@codesourcery.com> wrote:

> Jason Merrill <jason@redhat.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)).

It seems pretty clear to me, though the comment in tree.h is wrong.
__attribute ((packed)) means use the smallest alignment possible, unless a
greater alignment is specified with __attribute ((aligned (n))).  So
DECL_PACKED means "don't pad to an alignment greater than DECL_ALIGN".

> 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.

This sounds interesting, but I think that one integer and two flags is
actually what we need.

> The semantics are that *_MIN_ALIGN is the minimum alignment to enforce
> for a type or object

Yes.

> and *_MAX_ALIGN is the maximum alignment that can be assumed for a type
> or object.

No!  That's another meaning of *_MIN_ALIGN.  The enforced alignment is also
the alignment that can be assumed.  These are the two parties to the
alignment contract.

DECL_MAX_ALIGN would be the maximum alignment that can be applied to an
object.  But if you want to specify a maximum alignment at all, I can't
think of a situation in which we would a maximum different from the
minimum, so a flag should be adequate.

We also still need to be able to suppress the effects of
BIGGEST_FIELD_ALIGNMENT, which is why we have DECL_USER_ALIGN in the first
place.

So, we need:

A numerical alignment.
A flag which says "no, really, don't reduce the alignment, even if the ABI
  says to."
A flag which says "don't add extra padding."

It's not clear to me that we need the second flag for types.
The first flag is only really meaningful for FIELD_DECLs, and the second is only
really meaningful for VAR_DECLs.

Currently, both flags use DECL_USER_ALIGN.

Option A is to declare this to be intended, and make the one-line fix to
do_type_align to only copy TYPE_USER_ALIGN to DECL_USER_ALIGN for
FIELD_DECLs.

Option B is to use a different macro for the second flag.  DECL_PACKED
already means "don't increase the alignment", so it seems appropriate to
use it in this context, too.

Currently, there's no way to declare a misaligned VAR_DECL.  Do we care?

Jason

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Geert Bosch]

On Thursday, Apr 24, 2003, at 13:16 America/New_York, Jason Merrill 
wrote:
> I was referring to what dewar said here:
>
> On Mon, 21 Apr 2003 17:35:51 -0400 (EDT), dewar@gnat.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.

Exactly. A TYPE_ALIGN of 4 means that any variable of the type is
aligned to at least 4. So the maximum alignment the compiler can
assume for any pointer to a 4-byte aligned type is 4.

>> 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.
No it does not. Note that this is the case where no DECL_ALIGN has been
specified. Such as:
   type T is record
      X, Y, Z : Unsigned_16; -- 16-bit unsigned type
   end T;
   for T'Size use 48; --  48 bits
   for T'Alignment use 2;

   R : T := (1, 2, 3);
   Put (R'Alignment);

This may output a value that is a multiple of 2. Here the compiler
might decide to align R on a 8-byte boundary for efficiency. This
may enable the initialization to be done with a single 64-bit write,
for example. Of course, the knowledge about the better alignment
of R will get lost when passing (a pointer to) it to another
function. Still, increasing the alignment of objects is a
significant optimization that can speed up code immensely.
This will only be more true when the compiler will learn
more about vector instructions.

>> 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.
Note where you write "field", this really means "component of a
composite type", where a composite type can either be a record
or array.
> 4) For objects, we want to be able to force a minimum alignment.
Yes, where minimum alignment is not smaller than the type alignment.
> 5) For objects, we want to be able to force an exact alignment for 
> building up special sections (and for other reasons?).
How would this interact with reordering of objects (for example,
sorting by decreasing size, or for increasing cache efficiency)?
Also, do we guarantee that the compiler will not decide to output
extra objects between user-defined ones?
> 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.
Agreed.
>
> 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.

I don't think inheriting is a good idea, even for 4. This way
we loose the capability to over-align objects for which no specific
alignment was specified. It is important that we can do this,
especially as it allows small records to be stored in registers.
> 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?

I'm in favor of A, since it differentiates between the case where
the compiler has freedom to choose the alignment that gives the
most efficient code on each machine and the case where the user
has good reasons to pin down the details.

   -Geert

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill]

On Thu, 24 Apr 2003 15:31:39 -0400, Geert Bosch <bosch@gnat.com> wrote:

> On Thursday, Apr 24, 2003, at 13:16 America/New_York, Jason Merrill wrote:
>> I was referring to what dewar said here:
>>
>> On Mon, 21 Apr 2003 17:35:51 -0400 (EDT), dewar@gnat.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.
>
> Exactly. A TYPE_ALIGN of 4 means that any variable of the type is
> aligned to at least 4. So the maximum alignment the compiler can
> assume for any pointer to a 4-byte aligned type is 4.

Agreed.

>>> Specifying an alignment for an object means "don't reduce". 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.

> No it does not. Note that this is the case where no DECL_ALIGN has been
> specified.

Huh?  The testcase quoted above specifies the alignment for an object,
which to me means setting DECL_ALIGN.

> Such as:
>    type T is record
>       X, Y, Z : Unsigned_16; -- 16-bit unsigned type
>    end T;
>    for T'Size use 48; --  48 bits
>    for T'Alignment use 2;
>
>    R : T := (1, 2, 3);
>    Put (R'Alignment);
>
> This may output a value that is a multiple of 2.

Agreed.  But what do you think about dewar's testcase?

>> 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.
> Note where you write "field", this really means "component of a
> composite type", where a composite type can either be a record
> or array.

Good point.  But how would this be represented for an array?  I suppose by
reducing TYPE_ALIGN on the element type, so we need to be able to do that
as well.

>> 4) For objects, we want to be able to force a minimum alignment.
> Yes, where minimum alignment is not smaller than the type alignment.

Yes.

>> 5) For objects, we want to be able to force an exact alignment for
>> building up special sections (and for other reasons?).
> How would this interact with reordering of objects (for example,
> sorting by decreasing size, or for increasing cache efficiency)?
> Also, do we guarantee that the compiler will not decide to output
> extra objects between user-defined ones?

Good point; presumably we would want the same flag to suppress all such
optimizations.

>> 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.
> Agreed.
>>
>> 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.
>
> I don't think inheriting is a good idea, even for 4. This way
> we loose the capability to over-align objects for which no specific
> alignment was specified.

No, we don't.  4 just specifies a minimum; you can still over-align such an
object.  According to dewar, specifying the alignment for an object in Ada
means both 4 and 5.  It's not clear to me that we want the internal
representation to work the same way.

> It is important that we can do this, especially as it allows small
> records to be stored in registers.

Agreed.

>> 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?
>
> I'm in favor of A, since it differentiates between the case where
> the compiler has freedom to choose the alignment that gives the
> most efficient code on each machine and the case where the user
> has good reasons to pin down the details.

Both solutions do that.  It's just a question of which flag to use
internally.

Jason

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 24, 2003 at 04:30:44AM +0100, Jason Merrill wrote:
> Does this make sense to everyone?

Yes.  So long as we rename these flags to avoid confusion.


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    But the compiler can't tell whether, when you specify alignment for a
    type, you mean for interface or for efficiency, so I think it
    shouldn't make an assumption that it's to be used only for the former
    case like you seem to believe it should do.

No, I don't believe that, but it's not relevant.  Because it *might*
have been meant for interface, the compiler is not allowed to change
the alignment of types.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 22, 2003, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     But the compiler can't tell whether, when you specify alignment for a
>     type, you mean for interface or for efficiency, so I think it
>     shouldn't make an assumption that it's to be used only for the former
>     case like you seem to believe it should do.

> No, I don't believe that, but it's not relevant.  Because it *might*
> have been meant for interface, the compiler is not allowed to change
> the alignment of types.

The point is that you're saying it could increase the alignment of an
object in spite of a user-specified alignment for its type.  You can't
tell whether the alignment was defined for interface, space or
performance, so a user-specified alignment for a type should be
obeyed.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> And the reason is as I said: you specify alignment for a type both for
> interface and efficiency reasons, but for an object only for the latter.

Not quite. consider

   type R is array (Natural range <>) of Character;
   for R'Alignment use 1;

   X : R (1 .. 100);
   pragma Import (C, X);

now for the above, the generated code can only assume an alignment of 1.

But we might want to do

  Y : R (1 .. 1000);
  for Y'Alignment use 8;
  pragma Export (C, Y);

in a case where the C code expects an alignment for the object of 8 for
correct operation.

So even for objects, specifying an alignment different from that for the
type may be appropriately needed for functional correctness.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jamie Lokier]

Robert Dewar wrote:
> So even for objects, specifying an alignment different from that for the
> type may be appropriately needed for functional correctness.

The object alignment has to be >= the type alignment, doesn't it?

At the moment, in C, you can create a static object whose alignment is
less than its type's alignment.  The generated code to access the
object does a misaligned access, which is incorrect on some
architectures - assuming those accesses are supposed to have defined behaviour.

-- Jamie

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Oh.  I like yours more!  Much simpler, otherwise you still need code
    in the compiler to dereference at small alignments, which there
    doesn't seem to be at present.

Sure it is.  emit_block_move would handle the case just fine for aggregate
types.  Of course this is more problematic for scalars, but if you do it
indirectly via a BLKmode object, it'll work, though that's probably more
trouble than it's worth.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Are you saying that it should be an error to take the address of such
    an object?

What I was thinking was more that it should be an error to create an object
whose alignment is less than that of its type, but you correctly point out
that an alternate solution is to allow that but, like a bitfield, to forbid
taking its address.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jamie Lokier]

Richard Kenner wrote:
>     Are you saying that it should be an error to take the address of such
>     an object?
> 
> What I was thinking was more that it should be an error to create an object
> whose alignment is less than that of its type, but you correctly point out
> that an alternate solution is to allow that but, like a bitfield, to forbid
> taking its address.

Oh.  I like yours more!  Much simpler, otherwise you still need code
in the compiler to dereference at small alignments, which there
doesn't seem to be at present.

(Another solution is to say that the object's type has the same
alignment as the object itself (which may be different from the type
used in the object's declaration)).

Then you could take its address and dereference it, getting (in
principle) code which does handle the smaller alignment, and the
ability to pass that address around.

-- Jamie

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

I really think you are making this unnecessarily complex here because
I can't follow most of what you are writing.

    > Now consider a function that takes an object of type T that is *not* part
    > of the current compilation.  When generating code to dereference P, it is
    > not allowed to assume that the alignment of the object pointed to by P
    > is *more* than four bytes.

    This I understood already.  I think everyone sees this.

Actually not, because that's the key point in below:

    <lightbulb>
      Oh, I see why you mustn't increase alignment on types!  Thanks!
    </lightbulb>

If the above were obvious, so would this have been.

    > So doing so would be conforming to the standard.

    Somebody brought up an example where that might not be reasonable:
    multiple object in a special linker section, and the programmer
    expects them to be laid out as if in an array.  

Yes, but it's important to distinguish between what's "conforming" and
what's "reasonable".  As Robert Dewar points out, it's comforming to
implement multiplication as a loop over addition, but not reasonable.
But you can't try to determine what's "reasonable" by consulting a
standards document.

    Ok, now I agree it is practical to want to reduce an object's
    alignment for storage purposes.  (But isn't that why we have
    __attribute__((packed))?)

Yes.

    The essential quirk is this: whenever you take the address of an
    object, if you have specified the object's alignment and it is less
    than that of the original type, 

That should be an error.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jamie Lokier]

Richard Kenner wrote:
>     The essential quirk is this: whenever you take the address of an
>     object, if you have specified the object's alignment and it is less
>     than that of the original type, 
> 
> That should be an error.

Are you saying that it should be an error to take the address of such
an object?

-- Jamie

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    So, starting from the second (typedef) sample, if I write:

	__typeof__(i) * ptr = &i;
	use (*ptr);

    That should be equivalent to:

	T2 * ptr = &i;
	use (*ptr);

    The code for `use' may assume that the pointer has at least an
    alignment of 2, i.e. the least significant bit of the pointer is zero?

In this case, "use" should know what is being pointed to, so I don't
understand your example at all.

    Robert Dewar, on behalf of Ada, seems to think that the object
    alignment specification implies a _maximum_ alignment as well as a
    minimum.  For fields in structures this is relevant.  But for data
    variables?

This isn't an Ada issue, but a generic one, and I also raised the point.
The issue is one of interfacing.

Consider a type P that is a pointer to type T where I say that type
T has 4-byte alignment.  Now consider a function which is passed an
object of type T.  If that function is not part of the current compilation,
the specifcation of an alignment for T means that the compiler must ensure
that any object of type T must be aligned to *at least* 4 bytes since the
function is entitled to assume that.

Now consider a function that takes an object of type T that is *not* part
of the current compilation.  When generating code to dereference P, it is
not allowed to assume that the alignment of the object pointed to by P
is *more* than four bytes.

This means that it is an error to change the alignment of the *type*
in either direction from what the user specified.

    I have always expected that a user-specific alignment attribute can
    only increase the alignment of a type or object, not decrease it.
    After all, an object with alignment 8 *is* an object with alignment 4,
    for pointer dereferences and arithmetic purposes.

Except in the case above, where you are *importing* an object that type
and need to know what code to generate.  The reference to Ada is just that
these things are discussed specifically in the Ada RM, but they really apply
just as well to GNU C.

    But now I see that decreasing alignment is sometimes useful, because
    that influences how data is packed in memory, which is useful in some
    data structures and things like variables in special sections.

    It seems that in Ada, this "exact alignment" constraint is a language
    requirement.  (Is this correct, Robert?)

Be careful to distinguish the alignment of *type* with the alignment of
an object of that type.  Also be careful to realize that an implementation
must only provide an 'as if' implementation of the standard.

It is certainly true in Ada that if you have
	for x'alignment use 4;
then if you later ask for x'alignment, you must get 4 (bytes).  It's
also true that x'address must be a multiple of 4.  But if the compiler
were actually to tell the linker to align X to 8 bytes, there would be no
way to distinguish that case from the case where it just happened to be
aligned at that boundary.  So doing so would be conforming to the standard.

So the issue with objects is not conformance, but what's "best".  To
me, it seems that if the user goes to the trouble of specifying an
alignment for an object, they are doing so for a reason and it should
not be overriden unless there's a good reason to do that (e.g.,
minimum alignment on a machine, like S390).

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jamie Lokier]

Richard Kenner wrote:
> Consider a type P that is a pointer to type T where I say that type
> T has 4-byte alignment.  Now consider a function which is passed an
> object of type T.  If that function is not part of the current compilation,
> the specifcation of an alignment for T means that the compiler must ensure
> that any object of type T must be aligned to *at least* 4 bytes since the
> function is entitled to assume that.
> 
> Now consider a function that takes an object of type T that is *not* part
> of the current compilation.  When generating code to dereference P, it is
> not allowed to assume that the alignment of the object pointed to by P
> is *more* than four bytes.

This I understood already.  I think everyone sees this.

> This means that it is an error to change the alignment of the *type*
> in either direction from what the user specified.
> 
>     I have always expected that a user-specific alignment attribute can
>     only increase the alignment of a type or object, not decrease it.
>     After all, an object with alignment 8 *is* an object with alignment 4,
>     for pointer dereferences and arithmetic purposes.
> 
> Except in the case above, where you are *importing* an object that type
> and need to know what code to generate.  The reference to Ada is just that
> these things are discussed specifically in the Ada RM, but they really apply
> just as well to GNU C.

<lightbulb>
  Oh, I see why you mustn't increase alignment on types!  Thanks!
</lightbulb>

Naturally, an object cannot have a smaller alignment than the type
used to access it - that would lead to code generation errors.

That's why when I write:

	typedef int T __attribute__((aligned(16)));
	T x;

It is reasonably to expect to be able to access x through a pointer of
type T*, so I expect the *object* x to be allocated with alignment at
least 16 - because that's required for compatibility with the type.

If I now write:

	T y __attribute__((aligned(2)));

According to your rules I'd expect y to be allocated with alignment 2.
This implies that it is an error to access y through a pointer of type T*.

Consequently, &y must have type "T __attribute__((aligned(2)))", and
it would be a type error to assign it to a variable of type T*.

> It is certainly true in Ada that if you have
> 	for x'alignment use 4;
> then if you later ask for x'alignment, you must get 4 (bytes).  It's
> also true that x'address must be a multiple of 4.  But if the compiler
> were actually to tell the linker to align X to 8 bytes, there would be no
> way to distinguish that case from the case where it just happened to be
> aligned at that boundary.  So doing so would be conforming to the standard.

Somebody brought up an example where that might not be reasonable:
multiple object in a special linker section, and the programmer
expects them to be laid out as if in an array.  In practice an
object's size is usually a multiple of its alignment, so this isn't
usually a problem.

> So the issue with objects is not conformance, but what's "best".  To
> me, it seems that if the user goes to the trouble of specifying an
> alignment for an object, they are doing so for a reason and it should
> not be overriden unless there's a good reason to do that (e.g.,
> minimum alignment on a machine, like S390).

Ok, now I agree it is practical to want to reduce an object's
alignment for storage purposes.  (But isn't that why we have
__attribute__((packed))?)

Filling in some of the details: an object's alignment should inherit
from its type, including explicit type alignment attributes, though it
should be possible to override the type's alignment with an explicit
alignment attribute on the object.

The type of an object so declared includes the explicit object
alignment attribute, which overrides the original type alignment.

A pointer to a type of smaller alignment cannot be implicitly
converted to a pointer to the same type of larger alignment.

The only ugly part of this is that a user-specified alignment on a
type _increases_ the alignment, whereas a user-specified alignment on
an object will sometimes _decrease_ it.

This leads to the situation where I might reasonably have to write
code using a typedef to get usable code.  Here is a an example which
has well defined semantics according to your rules, but does not do
what some kinds of program require:

	#include "3rd_party.h"
	  -> defines "struct Foo { /* decls... */ };"
	...
	/* Force min 8-byte alignment so I can use 3 "tag" bits on pointers. */
	/* FIXME: This can reduce alignment and makes &my_foo
	   incompatible with the type "struct Foo *". */
	struct Foo my_foo __attribute__((aligned(8)));

	/* FIXME: It's an error to write do_something(&my_foo). */
	void do_something (struct Foo *);

The above is valid according to your rules and may actually be quite
useful, but in many programs it would not be what I'd want.  To get
what I'd want I'd have to write this instead:

	/* Force min 8-byte alignment so I can use 3 "tag" bits on pointers. */
	typedef struct Foo Foo_with_alignment __attribute__((aligned(8)));
	Foo_with_alignment my_foo;

Or this:

	/* I'm not sure if this works. */
	__typeof__(struct Foo __attribute__((aligned(8)))) my_foo;

Or this:

	struct Foo my_foo __attribute__((aligned(__alignof__(struct Foo) > 8
						 ?__alignof__(struct Foo):8)));

The essential quirk is this: whenever you take the address of an
object, if you have specified the object's alignment and it is less
than that of the original type, the resulting pointer is incompatible
with a pointer to the original type.  Hence the FIXME above.

That's not to say there's a problem with those semantics, but it is a
a bit counterintuitive that the second code sample does the right
thing for certain programs, despite appearing very similar to the first.

By the way, I've said that &my_foo is incompatible with struct Foo *.
GCC _doesn't_ complain about about such assignments, in fact it
doesn't even warn about them.

This means that the compiler will generated code that can fail with an
alignment fault on some architectures.  Specifically, this will fail
at run time on anything that traps on misalignment:

	short s = 1;
	int x __attribute__((aligned(2))) = 2;
	int * px = &x;

	int main() {
		return *px;
	}

Unfortunately I noticed that just "return x" will also do misaligned
accesses on every architecture I tried, including ARM2 where it will
return the wrong value.  I thought GCC was supposed to open code
accesses to low alignments properly?

-- Jamie

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    So if you turn:

    T i __attribute__((align(2)));
    T j __attribute__((align(2)));

    into

    typedef T T2 __attribute__((align(2)));
    T2 i, j;

    you say we could get different code?  

I say so, yes.

And the reason is as I said: you specify alignment for a type both for
interface and efficiency reasons, but for an object only for the latter.
So there is a difference in meaning between these two constructs.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jamie Lokier]

Richard Kenner wrote:
>     So if you turn:
> 
>     T i __attribute__((align(2)));
>     T j __attribute__((align(2)));
> 
>     into
> 
>     typedef T T2 __attribute__((align(2)));
>     T2 i, j;
> 
>     you say we could get different code?  
> 
> I say so, yes.
> 
> And the reason is as I said: you specify alignment for a type both for
> interface and efficiency reasons, but for an object only for the latter.
> So there is a difference in meaning between these two constructs.

So, starting from the second (typedef) sample, if I write:

	__typeof__(i) * ptr = &i;
	use (*ptr);

That should be equivalent to:

	T2 * ptr = &i;
	use (*ptr);

The code for `use' may assume that the pointer has at least an
alignment of 2, i.e. the least significant bit of the pointer is zero?

That seems to imply that `i' must have an alignment of at least 2, if
it is declared using the typedef.

This is also true if `i' is declared with object alignment, as in the
first code sample, as `T i __attribute__ ((aligned (2)))' as well.

So what is the difference?

Robert Dewar, on behalf of Ada, seems to think that the object
alignment specification implies a _maximum_ alignment as well as a
minimum.  For fields in structures this is relevant.  But for data
variables?


I have always expected that a user-specific alignment attribute can
only increase the alignment of a type or object, not decrease it.
After all, an object with alignment 8 *is* an object with alignment 4,
for pointer dereferences and arithmetic purposes.

From a C programming point of view, I tend to think of the pointer
address constraint as the whole reason for specifying alignment.  (If
I want to control structure layout, I'll use
`__attribute__((packed))').  And, for this, any reason for a type or
object to have an alignment should only be able to _increase_ the value.

But now I see that decreasing alignment is sometimes useful, because
that influences how data is packed in memory, which is useful in some
data structures and things like variables in special sections.

It seems that in Ada, this "exact alignment" constraint is a language
requirement.  (Is this correct, Robert?)

When there is a mechanism for limiting the alignment of an object to
something below it's natural alignment, this affects the correctness
of compiler-generated code which dereferences pointers to it, and when
performing arithmetic with those pointers.dereference that type

This suggests two kinds of user alignment constraint:

	__attribute__((aligned(x)))
		- forces type or object or field to have AT LEAST alignment x

	__attribute__((exactly_aligned(x)))
		- forces type or object or field to have EXACTLY alignment x,
		  overriding natural alignment constraints.

Both of these should inherit from types to objects and fields, AND
they inherit from objects and fields back to types, when the user does
`__typeof__' or uses the address-of operator (`&' in C).

In other words, assuming that the `exactly_aligned' attribute has the
qualities that I belive Robert thinks `aligned' should have for objects:

	/* sizeof(int) == __alignof__(int) == 4. */

	typedef int T __attribute_((exactly_aligned(2)));
	int x __attribute_((exactly_aligned(2)));

	int __attribute((exactly_aligned(2))) * px1 = &x; /* Correct. */
	T * px2 = &x;	/* Correct. */
	int * px3 = &x;	/* Type error (just a warning?). */

	T y1 = *px1;	/* Fine, special code emitted by compiler. */
	T y3 = *px3;	/* Crashes due to access alignment fault... */

Whereas, if you replace each occurence of `exactly_aligned' with
`aligned' in the above, there will be no access alignment fault (or
compile time type error, whichever is implemented).

-- Jamie

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 21, 2003, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     So if you turn:
>     T i __attribute__((align(2)));
>     T j __attribute__((align(2)));

>     into

>     typedef T T2 __attribute__((align(2)));
>     T2 i, j;

>     you say we could get different code?  

> I say so, yes.

> And the reason is as I said: you specify alignment for a type both for
> interface and efficiency reasons, but for an object only for the latter.
> So there is a difference in meaning between these two constructs.

But the compiler can't tell whether, when you specify alignment for a
type, you mean for interface or for efficiency, so I think it
shouldn't make an assumption that it's to be used only for the former
case like you seem to believe it should do.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> You might.  It depends on what you're doing with that object.
> Perhaps it's been put into a special section and so smooshed
> into an array created at link time.  Indeed, that's *exactly*
> the case that caused us to respect USER_ALIGN in varasm.c at
> all costs.

In that case, you would specify an explicit alignment *for the
object*, which a compiler would take as a clear indication that
the alignment should not be increased. This shows why it is important
to know if the alignment from an object was explicitly specified
for the object.

We specify the alignment of a type to determine the treatment within
composites, but we do not necessarily expect that to not be increased
for stand alone objects.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 19, 2003, dewar@gnat.com (Robert Dewar) wrote:

> In that case, you would specify an explicit alignment *for the
> object*, which a compiler would take as a clear indication that
> the alignment should not be increased.

So if you turn:

T i __attribute__((align(2)));
T j __attribute__((align(2)));

into

typedef T T2 __attribute__((align(2)));
T2 i, j;

you say we could get different code?  It sounds to me like they
*should* be equivalent.  The compiler can't tell whether the user
meant the alignment of a type is meant for composites only or for
factoring of attributes in object declarations.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> Thanks, I do see your point now.  However, I still don't think the
> compiler should disregard alignment requirements set to the type just
> because an object is not part of a record.  I do agree that the
> compiler may do it, and it may even happen by chance, but the property
> of the type should carry over to objects and fields uniformly, in the
> absence of an overrider.  The same point you make for someone setting
> the alignment for an object to something different than the type's
> alignment could be made for someone setting the alignment for say a
> typedef, expecting it to affect all uses of the typedef.
> Distinguishing between type-specified and decl-specified alignments
> defeats this purpose.

yes, of course the properties of the type must carry over to objects. But
once again, if you specify an alignment of 1 for a big string (in fact
this is the default alignmment):

  type R is new string (1 .. 1000);
  for R'Alignment use 1;

Then most certainly any stand alone object of type R must have an alignment
of 1, but most certainly may have a larger alignment, and giving stand alone
objects of this type nice large alignments is in fact a very appropriate
optimization (and one that is quite target dependent, so we certainly do
NOT want the user to have to specify a large alignment explicitly).

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    > No, it's being overloaded for two *other* meanings:
    > 
    > (1) The user really did set the alignment of the object.
    > (2) The user really did set the alignment of the object's *type*.

    I see the two as equivalent.

I see them as very different because the semantics of setting the alignment
of a type and of an object are fundamentally different.  The first has both
efficiency and code generation impact, but the second has only the latter.

This is codified in the Ada RM, but actually applies to all languages.

When you set the alignment of a *type*, you are making an interface statement
about that type, more specifically about pointers to that type.  You are
requiring the compiler to align any objects of that type that it creates to
be at least as aligned as you specify but *also* stating that any objects of
that type *imported* to the code will have that minimum alignment, but aren't
guaranteeing it will have more than that alignment.  So the compiler is not
permitted to assume a larger alignment when it generates code to access
objects of that type (via a pointer, when it knows nothing else about the
object itself).

This means that the specification of the alignment of a type bounds the
compiler on both sides: it must ensure that any object it makes is *no less*
aligned, but it cannot generate code that assumes the alignment is *more*
than that specified.

So if the alignment of a type is specified, the alignment of the type cannot
be changed by the compiler: it must either honor that alignment or give an
error.

But specifying the alignment of an *object* is very different.  It's not
making a statement about an interface, but about efficiency.  If I specify
the alignment of an object, I'm asserting that I've analyzed accesses to the
object and determined the optimal alignment.

In which cases is the compiler allowed to override a user-specified
alignment?  Well, for types it must *never* override the alignment since that
would be an interface violation.

For objects, if an object is at least as aligned as that requested, it's
fine, so I'd argue that a compiler should feel free to over-align an object
for efficiency reasons even if the type's alignment is specified because
there's no reason not to.  On the other hand, if the *object's* alignment is
specified, one can presume it was done with a knowlege of what the optimal
alignment was so that overriding it is not a good idea.

However, if it *has* to be overriden, such as for the minimum alignment of
S390, it certainly *should* be since it's not an error to increase the
alignment of an object (as opposed to a type).

But, in some sense, this isn't even the point.

My major point is that decision of what alignment to actually give an
object may depend on lots of things, including:

(1) the target machine
(2) the language
(3) the mode and alignment of the type
(4) whether the alignment of the type was user-specified
(5) the alignment of the object
(6) whether the alignment of the object was user-specified

What we're doing now is not providing #6, but instead providing the "or"
of #4 and #6.  I see no justification for elminating potentially-useful
information.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    The fact of the matter is that this field is being overloaded
    for two meanings:

No, it's being overloaded for two *other* meanings:

(1) The user really did set the alignment of the object.
(2) The user really did set the alignment of the object's *type*.

      The user REALLY DID set the alignment, and expects it to
      be honored exactly as stated

Yes, but there's a fundamental ambiguity here.  If the user says he
wants an object aligned at a 4-byte boundary, is it an error to align
it to a page boundary?  Is there some requirement that we ensure that
every such object is at an address that has *exactly* the number of
low-order zeros as requested by the alignment and no more?

What, precisely, does "honored" mean here?

I'll have more to say about this, but tomorrow morning when I'm fresher.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 17, 2003 at 09:20:24PM -0400, Richard Kenner wrote:
> No, it's being overloaded for two *other* meanings:
> 
> (1) The user really did set the alignment of the object.
> (2) The user really did set the alignment of the object's *type*.

I see the two as equivalent.

> Yes, but there's a fundamental ambiguity here.  If the user says he
> wants an object aligned at a 4-byte boundary, is it an error to align
> it to a page boundary?

If aligning to a page boundary has the effect of inserting
padding that a 4-byte boundary wouldn't, yes.  I.e. the compiler
*shouldn't* emit ".p2align 13" in this situation.


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Ok, you got me curious.  Would you mind explaining to an Ada-clueless
    person how come these two cases can possibly be different?  In my
    C-centric view, I really can't see the difference.  Code snippets
    demonstrating the semantic difference would be highly appreciated.

You gave one in your previous message: if you specify the alignment of
a type, you don't want to see the alignment of the type made more
strict since that would affect *fields* of that type.  But you don't
mind if stand-alone objects of that type were aligned stricter.  If
you specifically set the alignment of an object, you are presumably
doing so because you *don't* want the object to be put at a stricter
alignment.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 17, 2003, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> But you don't mind if stand-alone objects of that type were aligned
> stricter.  If you specifically set the alignment of an object, you
> are presumably doing so because you *don't* want the object to be
> put at a stricter alignment.

Thanks, I do see your point now.  However, I still don't think the
compiler should disregard alignment requirements set to the type just
because an object is not part of a record.  I do agree that the
compiler may do it, and it may even happen by chance, but the property
of the type should carry over to objects and fields uniformly, in the
absence of an overrider.  The same point you make for someone setting
the alignment for an object to something different than the type's
alignment could be made for someone setting the alignment for say a
typedef, expecting it to affect all uses of the typedef.
Distinguishing between type-specified and decl-specified alignments
defeats this purpose.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 17, 2003 at 04:34:24PM -0400, Richard Kenner wrote:
> But you don't mind if stand-alone objects of that type were
> aligned stricter.

You might.  It depends on what you're doing with that object.
Perhaps it's been put into a special section and so smooshed
into an array created at link time.  Indeed, that's *exactly*
the case that caused us to respect USER_ALIGN in varasm.c at
all costs.

The fact of the matter is that this field is being overloaded
for two meanings:

  (1) The user REALLY DID set the alignment, and expects it to
      be honored exactly as stated, and

  (2) The Ada front end is going about honoring Ada language
      semantics and doesn't want alignment increased in specific
      situations wrt types, but doesn't mind it being increased
      in other situations wrt objects.


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    I hope not if this would change the layout of a structure containing a
    member with the specified alignment requirement.  This is where
    propagating the user-requested alignment for a type into the field
    decl comes into play: by doing this, we make sure the alignment
    request is obeyed, regardless of whether it comes from the field decl
    or from its type.

Yes, but this is precisely the case you have been asking to see: if you
set the alignment of a type, you do *not* want a field of the type to
be stricter aligned, but you don't care about an object.  You *do* care
about the object if you *also* specify an alignment for it, which is why
you must distinguish between the two cases.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Well...  You can always compare DECL_USER_ALIGN with TYPE_USER_ALIGN,
    if you care strongly about that.  

No, you can't.  You can't distinguish between the cases where the alignment
is specified for the type and not the object and the case where it is
specified for both.

    But the point that whether the alignment came from a decl-specific
    attribute or from the type shouldn't make a difference.

Why not?  They are two *very* different things with different semantics.

    But why should the common case be more difficult and error-prone?  

Which is "the common case"?  Specifying the alignment of either in C is 
very rare since it is a GNU extension.  Specifying alignment in Ada is
much more common and there the most common case is specifying it for
types and not for objects.

    Do you have any situation in mind in which it is actually important to
    tell whether a decl-specific user-requested alignment came from the
    variable declaration or from its type?

Sure.  It's required to properly implement these specifications for Ada,
where the semantics of the two cases are completely different.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 17, 2003, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     Well...  You can always compare DECL_USER_ALIGN with TYPE_USER_ALIGN,
>     if you care strongly about that.  

> No, you can't.  You can't distinguish between the cases where the alignment
> is specified for the type and not the object and the case where it is
> specified for both.

I still don't see why it would make a difference, and why it can
possibly be correct to do anything different.

>     But the point that whether the alignment came from a decl-specific
>     attribute or from the type shouldn't make a difference.

> Why not?  They are two *very* different things with different semantics.

I don't see the difference.  To me, applying the align attribute to a
type has always been equivalent to applying the same attribute to all
declarations of that type, except those that override it with
something different.

>     But why should the common case be more difficult and error-prone?  

> Which is "the common case"?

Have the alignment specified for only one of them, and most likely to
types, which means (to me) that it applies to all declarations of that
type.

> Specifying alignment in Ada is much more common and there the most
> common case is specifying it for types and not for objects.

So we're in agreement on this point.

>     Do you have any situation in mind in which it is actually important to
>     tell whether a decl-specific user-requested alignment came from the
>     variable declaration or from its type?

> Sure.  It's required to properly implement these specifications for
> Ada, where the semantics of the two cases are completely different.

Ok, you got me curious.  Would you mind explaining to an Ada-clueless
person how come these two cases can possibly be different?  In my
C-centric view, I really can't see the difference.  Code snippets
demonstrating the semantic difference would be highly appreciated.

Waiting to be enlightened, :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Geert Bosch]

On Thursday, Apr 17, 2003, at 16:15 America/New_York, Alexandre Oliva 
wrote:
> Ok, you got me curious.  Would you mind explaining to an Ada-clueless
> person how come these two cases can possibly be different?  In my
> C-centric view, I really can't see the difference.  Code snippets
> demonstrating the semantic difference would be highly appreciated.
>

Below is an example which is required not to raise Program_Error:

with System.Storage_Elements; use System.Storage_Elements;
procedure T is

    type Point is record
       X, Y, Z : Long_Float;
    end record;

    type Path is array (Positive range <>) of Point;
    pragma Pack (Path);

    Q : Point;
    for Q'Alignment use 16;

begin
    if Q'Address mod 16 /= 0 then
       raise Program_Error;
    end if;
end T;


> Waiting to be enlightened, :-)

Hope the example helps. Yell if not :-)

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 17, 2003, Geert Bosch <bosch@gnat.com> wrote:

>> Waiting to be enlightened, :-)

> Hope the example helps. Yell if not :-)

'fraid it doesn't.  Only the alignment of variable Q seems to be
user-specified in this case, so it doesn't compare the two different
cases, which is the point of contention.  What if the alignment of the
Point record was defined as 16 as well?  What if it was defined to
something else?  What if the record alignment was defined by the user
but the alignment of variable Q wasn't?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> What I don't get is why such cases must be distinguished.  I mean, if
> an alignment is specified by the user for a type, is it not true that
> the user is also specifying the alignment for any objects of that
> type, except when overridden for a specific object?  It seems to me
> that this is the point of the change that propagates TYPE_USER_ALIGN
> to DECL_USER_ALIGN, and I can't see how this could possibly be
> incorrect.  I mean, if it is not, then, given:

Yes, you are specifying an alignment for objects of the type, but the
implementation is always free to give a larger alignment. Consider in
Ada

   type r is new string (1 .. 1000);
   for r'alignment use 1; -- that's also the default if not specified

   a,b : r;

a compiler may well decide to give larger alignment for a and b to improve
the efficiency of the code (e.g. for the assignment a := b).

An alignment specifies the minimum alignment that is guaranteed and that
can be assumed of all objects. It is just fine for a compiler to increase
the alignment to improve the code provided that does not violate other
specifications (e.g. a record that is layed out that contains components
of the type).

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 17, 2003, dewar@gnat.com (Robert Dewar) wrote:

> Yes, you are specifying an alignment for objects of the type, but the
> implementation is always free to give a larger alignment.

I hope not if this would change the layout of a structure containing a
member with the specified alignment requirement.  This is where
propagating the user-requested alignment for a type into the field
decl comes into play: by doing this, we make sure the alignment
request is obeyed, regardless of whether it comes from the field decl
or from its type.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    What I don't get is why such cases must be distinguished.  I mean, if
    an alignment is specified by the user for a type, is it not true that
    the user is also specifying the alignment for any objects of that
    type, except when overridden for a specific object?  

Perhaps, but the point is that if you set DECL_USER_ALIGN from
TYPE_USER_ALIGN you *can't tell* if it was "overridden for a specific
object" or not and that information is useful.

    It seems to me that this is the point of the change that propagates
    TYPE_USER_ALIGN to DECL_USER_ALIGN, and I can't see how this could
    possibly be incorrect.  

It might be reasonable for a "consumer" of these bits to do

	DECL_USER_ALIGN (decl) || TYPE_USER_ALIGN (TREE_TYPE (decl))

if it wanted that interpretation, but I think all four cases are
potentially different and the flags should be set up to be able to
distinguish them.  

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 17, 2003, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     What I don't get is why such cases must be distinguished.  I mean, if
>     an alignment is specified by the user for a type, is it not true that
>     the user is also specifying the alignment for any objects of that
>     type, except when overridden for a specific object?  

> Perhaps, but the point is that if you set DECL_USER_ALIGN from
> TYPE_USER_ALIGN you *can't tell* if it was "overridden for a specific
> object" or not and that information is useful.

Well...  You can always compare DECL_USER_ALIGN with TYPE_USER_ALIGN,
if you care strongly about that.  But the point that whether the
alignment came from a decl-specific attribute or from the type
shouldn't make a difference.

> It might be reasonable for a "consumer" of these bits to do

> 	DECL_USER_ALIGN (decl) || TYPE_USER_ALIGN (TREE_TYPE (decl))

But why should the common case be more difficult and error-prone?  Do
you have any situation in mind in which it is actually important to
tell whether a decl-specific user-requested alignment came from the
variable declaration or from its type?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> So there's no specific reason to have -C in ada/Makefile.in,
> I'll look into removing it at some point.

Don't you think that in the context of gcc, it is more convenient to have
the main program in C than in Ada?

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> Question to ACT: is "gnatbind -C" here for other than historical reasons
> (supporting previous gnatbind without the feature to generate Ada)?

Not at all, there are many reasons why people find it convenient to generate
a main program in C rather than Ada. This is a feature that is quite widely
used, and we certainly intend to keep supporting it.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Laurent Guerby]

On Fri, 2003-04-11 at 18:41, Robert Dewar wrote:
> > Question to ACT: is "gnatbind -C" here for other than historical reasons
> > (supporting previous gnatbind without the feature to generate Ada)?
> 
> Not at all, there are many reasons why people find it convenient to generate
> a main program in C rather than Ada. This is a feature that is quite widely
> used, and we certainly intend to keep supporting it.

By "here" I meant in ada/Makefile.in, not for general use.

So there's no specific reason to have -C in ada/Makefile.in,
I'll look into removing it at some point.

-- 
Laurent Guerby <guerby@acm.org>

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> No, that's actually OK since it is the property of the macros that
> modify alignment that if you start with the alignment that they
> produced, they produce that alignment again.  I suppose nobody has
> even formally documented this property, but it would be very hard to
> see why they would do anything else.

Well indeed it should be formally documented if we depend on it. But
in that case, I also see no harm in setting a "user defined" alignment
that corresponds to this default value.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> Why?  It seems like what it means is "the alignment of this type was set the
> way it is for a reason.  Please don't change it."  And that applies here.

Yes, that's exactly what we want in Ada, and the reason is that Ada has to
know the alignment. Furthermore, the semantics of this alignment are required
to be exactly what would be obtained if a confirming rep clause were given.

So either

a) the confirming rep clause (and setting USER_ALIGN) has no effect in this
case, in which case why bother about it.

or

b) the confirming rep clause WOULD have an effect if USER_ALIGN is only set
in the presence of this rep clause. In that case we must set USER_ALIGN 
regardless, since we don't want the addition of the confirming rep clause
to have any effect.

Seems clear to me!

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    > But it *isn't* set in Ada! 

    Ulrich's experience clearly belies this.

What I meant is that the Ada front end doesn't set it, not that it
isn't getting set.  Instead, it gets set from TYPE_USER_ALIGN, which
seems wrong to me because it doesn't properly distinguish (in any
language) the cases where an alignment is specified for a type
vs. when its specified for a decl.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Alexandre Oliva]

On Apr 10, 2003, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> Instead, it gets set from TYPE_USER_ALIGN, which seems wrong to me
> because it doesn't properly distinguish (in any language) the cases
> where an alignment is specified for a type vs. when its specified
> for a decl.

What I don't get is why such cases must be distinguished.  I mean, if
an alignment is specified by the user for a type, is it not true that
the user is also specifying the alignment for any objects of that
type, except when overridden for a specific object?  It seems to me
that this is the point of the change that propagates TYPE_USER_ALIGN
to DECL_USER_ALIGN, and I can't see how this could possibly be
incorrect.  I mean, if it is not, then, given:

typedef T foo __attribute__((aligned(N));
foo bar;
foo baz __attribute__((aligned(N));

bar and baz might have different alignment requirements, which feels
wrong to me.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Richard Henderson wrote:

>On Thu, Apr 10, 2003 at 06:35:54PM -0400, Richard Kenner wrote:
>>     I definitely think there's a bug in that the Ada front end sets
>>     DECL_USER_ALIGN for these objects and the C front end (in response to
>>     the auto-generated files) does not.  That mis-match should be
>>     addressed in some way -- either by not setting DECL_USER_ALIGN in Ada
>> 
>> But it *isn't* set in Ada! 
>
>Ulrich's experience clearly belies this.

You probably missed one of the forks of this thread; to clear 
up possible confusion, what happens is that the Ada frontend
does in fact not set DECL_USER_ALIGN, only TYPE_USER_ALIGN.

It is the middle-end (stor-layout.c), that copies TYPE_USER_ALIGN
to DECL_USER_ALIGN.  And in fact, this is done only as a result
of a patch by Jason Merrill as of last week:

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00209.html

As this patch is a bit complex, I'm not sure if the change in
behaviour (for Ada) was intended or not, but this patch is
definitely the immediate cause of the s390x / Ada problems ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    I definitely think the bug is *not* in varasm.c.  If I write
    "double x __attribute__((aligned(1)))", I expect to see 

        .comm   x,8,1
    not
	.comm	x,8,8

    in the assembly file.

of course.  That's because in this case you are setting the alignment
of the *object*, not the *type*.

    I definitely think there's a bug in that the Ada front end sets
    DECL_USER_ALIGN for these objects and the C front end (in response to
    the auto-generated files) does not.  That mis-match should be
    addressed in some way -- either by not setting DECL_USER_ALIGN in Ada

But it *isn't* set in Ada! 

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 10, 2003 at 06:35:54PM -0400, Richard Kenner wrote:
>     I definitely think there's a bug in that the Ada front end sets
>     DECL_USER_ALIGN for these objects and the C front end (in response to
>     the auto-generated files) does not.  That mis-match should be
>     addressed in some way -- either by not setting DECL_USER_ALIGN in Ada
> 
> But it *isn't* set in Ada! 

Ulrich's experience clearly belies this.


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[David Edelsohn]

>>>>> Richard Henderson writes:

>> But it *isn't* set in Ada! 

Richard> Ulrich's experience clearly belies this.

	What Kenner means is that the Ada front-end is not setting
DECL_USER_ALIGN itself.  It is setting TYPE_USER_ALIGN and the recent
change to stor-layout.c is causing DECL_USER_ALIGN to be set based on
TYPE_USER_ALIGN.

	Yes, DECL_USER_ALIGN is set when using Ada, but Ada itself is not
setting it explicitly.  You're both right.

David

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Yes.  64-bit S/390 requires 2-byte alignment.  The alignment can be 2
    or anything stricter than 2 for 64-bit S/390.  GNU Ada currently is
    setting USER_ALIGN to 1 for some objects, which is breaking GNU Ada on
    64-bit S/390.

Actually, it *isn't* setting DECL_USER_ALIGN for any objects and I
believe that's correct.  It's stor-layout.c that is setting it from
TYPE_USER_ALIGN and that seems quite wrong: there is a difference
between specifying the alignment of a type and that of an object and
DECL_USER_ALIGN means the latter.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Wel then there is some other funny behavior, which is that it is widely
    understood that provinding a confirming rep clause shoud have no effect
    at all on the generated code.

    So if it should make no difference to the code whether a confirming rep
    clause is given, how can it be possbiule in some cases that it should be
    omitted.

No, that's actually OK since it is the property of the macros that
modify alignment that if you start with the alignment that they
produced, they produce that alignment again.  I suppose nobody has
even formally documented this property, but it would be very hard to
see why they would do anything else.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    1) If the front-end has to specify USER_ALIGN so that the alignment is
    static and the backend will not modify the alignment,

    2) and the front-end is allowed to align the type more strictly,

    3) and the target has minimum alignment requirements,

    then it seems that the front-end needs to know the minimum alignment so
    that it does not specify USER_ALIGN which conflicts with the target
    requirements.  The front-end will use USER_ALIGN and will specify an exact
    alignment, but the alignment will be compatible with the target's own
    minimum alignment requirements.

I don't understand what a "minimum alignment requirement" might mean.
Would it apply to types or only to objects?  

If only to objects, saying that an object is 1-byte aligned allows
*any* alignment.

But I can't find a macro that specifies an minimum alignment.  What is
it called?

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> If only to objects, saying that an object is 1-byte aligned allows
Richard> *any* alignment.

	Yes.  64-bit S/390 requires 2-byte alignment.  The alignment can
be 2 or anything stricter than 2 for 64-bit S/390.  GNU Ada currently is
setting USER_ALIGN to 1 for some objects, which is breaking GNU Ada on
64-bit S/390.

Richard> But I can't find a macro that specifies an minimum alignment.  What is
Richard> it called?

	This would be a new macro, or result of querying an existing macro
with a test alignment of 1 byte to examine what modification to that
alignment a GCC port currently produces.

David

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

>         Interpret "type" as "primitive type" in your nomenclature.  As
> long as the user does not explicitly override the default alignment of the
> primitive type (probably the natural alignment, or whatever the language
> or target ABI specifies), the compiler should not need to annotate the GCC
> type information with an explicit user type.

Wel then there is some other funny behavior, which is that it is widely
understood that provinding a confirming rep clause shoud have no effect
at all on the generated code.

So if it should make no difference to the code whether a confirming rep
clause is given, how can it be possbiule in some cases that it should be
omitted.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Seems to me that if this is happening, it's a failing of the
    layout_type interface.  It definitely seems Wrong to abuse
    *USER_ALIGN for this.

Why?  It seems like what it means is "the alignment of this type was set the
way it is for a reason.  Please don't change it."  And that applies here.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 10, 2003 at 05:49:40PM -0400, Richard Kenner wrote:
> Why?  It seems like what it means is "the alignment of this type was set the
> way it is for a reason.  Please don't change it."  And that applies here.

I'll concede that there's still too much language-specific
widgetry in layout_type, which causes you to want to set
such a flag, but that's as far as I'm willing to go.

Perhaps the short-term solution is as you suggest -- a new
lang hook such that Ada can avoid setting DECL_USER_ALIGN
when the languages allows a larger alignment to be used for
particular objects.

I definitely think the bug is *not* in varasm.c.  If I write
"double x __attribute__((aligned(1)))", I expect to see 

        .comm   x,8,1
not
	.comm	x,8,8

in the assembly file.

I do like Ulrich's change to the s390x backend to cope with
variables explicitly declared with 1 byte alignment.

I definitely think there's a bug in that the Ada front end
sets DECL_USER_ALIGN for these objects and the C front end
(in response to the auto-generated files) does not.  That
mis-match should be addressed in some way -- either by not
setting DECL_USER_ALIGN in Ada or by tagging the variables
with attribute aligned in C.  I think it's clear that the
former solution would be preferred, since it would result
in better code for this platform.  But this is up to yall.


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Laurent Guerby]

On Fri, 2003-04-11 at 00:06, Richard Henderson wrote:
> That mis-match should be addressed in some way -- either by not
> setting DECL_USER_ALIGN in Ada or by tagging the variables
> with attribute aligned in C. 

Note that the Ada binder generated C file can probably be replaced by an
Ada file if you remove the "-C" argument to gnatbind and tweak
a bit further the Makefile.

Question to ACT: is "gnatbind -C" here for other than historical reasons
(supporting previous gnatbind without the feature to generate Ada)?

-- 
Laurent Guerby <guerby@acm.org>

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Arnaud Charlet]

> Question to ACT: is "gnatbind -C" here for other than historical reasons
> (supporting previous gnatbind without the feature to generate Ada)?

Yes, it is also there to detect and work around cases where the Ada and the C
compiler won't handle main files identically (e.g. special handling of
the "main" function, ...).

Arno

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Laurent Guerby]

On Fri, 2003-04-11 at 12:48, Arnaud Charlet wrote:
> > Question to ACT: is "gnatbind -C" here for other than historical reasons
> > (supporting previous gnatbind without the feature to generate Ada)?
> 
> Yes, it is also there to detect and work around cases where the Ada and the C
> compiler won't handle main files identically (e.g. special handling of
> the "main" function, ...).

So in the context of the compiler bootstrap process, since
we know the compiler (GCC/GNAT), there's no reason to use -C, right?

Yes of course in other contexts -C might prove useful :).

-- 
Laurent Guerby <guerby@acm.org>

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Then it sounds like we need a way for the port to specify or the
    front-end to query the minimum alignment allowed for the target.  This
    would allow the front-end to statically know the alignment of the type
    while maintaining the target requirements.

The issue isn't *minimum*, but *exact*.  The front end needs to know what 
the alignment for a particular type will be.  Yes, it is possible for it
to make on-the-fly calls to the back end to lay out types incrementally, but
that's a very difficult thing to do due to dependencies of types on variables.
It's not clear it's worth it.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> The issue isn't *minimum*, but *exact*.  The front end needs to know what 
Richard> the alignment for a particular type will be.  Yes, it is possible for it
Richard> to make on-the-fly calls to the back end to lay out types incrementally, but
Richard> that's a very difficult thing to do due to dependencies of types on variables.
Richard> It's not clear it's worth it.

	I am sorry that I was not clear enough in my previous response.

1) If the front-end has to specify USER_ALIGN so that the alignment is
static and the backend will not modify the alignment,

2) and the front-end is allowed to align the type more strictly,

3) and the target has minimum alignment requirements,

then it seems that the front-end needs to know the minimum alignment so
that it does not specify USER_ALIGN which conflicts with the target
requirements.  The front-end will use USER_ALIGN and will specify an exact
alignment, but the alignment will be compatible with the target's own
minimum alignment requirements.

David

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Maybe.  I'm a bit confused as to why *_USER_ALIGN would be set for
    "most types" though.  Seems to me that should only be done if the
    USER did something specific, like "for x'alignment use N".

Because of the requirement that the alignment of most types be *static*.
So they cannot be changed from what the front end thinks they are, whether
or not they got that way by explicit user action.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> Because of the requirement that the alignment of most types be *static*.
Richard> So they cannot be changed from what the front end thinks they are, whether
Richard> or not they got that way by explicit user action.

	Then it sounds like we need a way for the port to specify or the
front-end to query the minimum alignment allowed for the target.  This
would allow the front-end to statically know the alignment of the type
while maintaining the target requirements.

David

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 10, 2003 at 05:40:55PM -0400, Richard Kenner wrote:
> Because of the requirement that the alignment of most types be *static*.
> So they cannot be changed from what the front end thinks they are, whether
> or not they got that way by explicit user action.

Seems to me that if this is happening, it's a failing of the
layout_type interface.  It definitely seems Wrong to abuse
*USER_ALIGN for this.


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    So, what you actually want to do is to set the alignment of the object
    to be *more* aligned than its type?  

Yes.

    Or, to phrase it another way, you want the object to be of a type
    which is more aligned than its declared type?

Not necessarily.  We had this discussion before.  I believe it should be
possible to have DECL_ALIGN > TYPE_ALIGN and likewise for DECL_SIZE.
If it's not, then why have them in the first place?

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

>         Yes, the type can have greater alignment.  However type normally
> does imply a minimum alignment and minimum size.  Specifying user
> alignment for a well-defined type seems redundant.

Well the front end must know statically the alignment of any non-primitive
type, so it makes some sense to specify it as having the value that the
front end thinks it has.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[David Edelsohn]

>>>>> Robert Dewar writes:

>> Yes, the type can have greater alignment.  However type normally
>> does imply a minimum alignment and minimum size.  Specifying user
>> alignment for a well-defined type seems redundant.

Robert> Well the front end must know statically the alignment of any non-primitive
Robert> type, so it makes some sense to specify it as having the value that the
Robert> front end thinks it has.

	Interpret "type" as "primitive type" in your nomenclature.  As
long as the user does not explicitly override the default alignment of the
primitive type (probably the natural alignment, or whatever the language
or target ABI specifies), the compiler should not need to annotate the GCC
type information with an explicit user type.

David

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Yes, the type can have greater alignment.  However type normally does
    imply a minimum alignment and minimum size.  Specifying user alignment
    for a well-defined type seems redundant.

You lost me.

If I have a record of two 16-bit fields, the natural alignment of that type
is 16 bits.  However, the user is allowed to specify an alignment of 32
bits for the type.

I'm not sure what your second sentence means, but it is indeed true
that the compiler cannot change the alignment of a type since it
bounds it in both directions: it gives the minimum alignment that an
object of that type created by the compiler is guaranteed to have, but
it also gives the *maximum* alignment that the compiler is allowed to assume
that a user-created object of that type will have.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> This is the terminology point that Robert alluded to.  If something
> has an alignment of 64 bits, it *also* has an alignment of 32 bits and
> of 16 bits, etc.  So an object that is aligned to 64 bits and is of a
> type that is aligned to 32 bits *has* "the properties (including
> alignment)" of its type.

It's not just that. It would also be fine to have

   type x is record ....
   for x'alignment use 2;

   xx : x;

   Put_Line (Integer'Image (XX'Alignment));

output a value of 4 or 8 or ...

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> Is it not true in Ada that if something is a particular type, then
> it has the properties (including alignment) of that type?
> 
> That sounds like a pretty fundamental part of the idea of 'type', not
> language-specific.

No, that is not the case, if type'alignment is set, then objects of the type
can have that alignment or a greater alignment. The same is true for 
type'size.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[David Edelsohn]

>>>>> Robert Dewar writes:


>> Is it not true in Ada that if something is a particular type, then
>> it has the properties (including alignment) of that type?
>> 
>> That sounds like a pretty fundamental part of the idea of 'type', not
>> language-specific.

Robert> No, that is not the case, if type'alignment is set, then objects of the type
Robert> can have that alignment or a greater alignment. The same is true for 
Robert> type'size.

	Yes, the type can have greater alignment.  However type normally
does imply a minimum alignment and minimum size.  Specifying user
alignment for a well-defined type seems redundant.

David

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Is it not true in Ada that if something is a particular type, then
    it has the properties (including alignment) of that type?

The other issue is that DECL_USER_ALIGN is supposed to indicate if an
alignment was specified *for a decl*.  If you want to know if an
alignment is specified for *the type of a decl*, you check
TYPE_USER_ALIGN (TREE_TYPE (decl)).  Some code may wish to do
something if *either* alignment was user-specified, but then it can
check *both* flags.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Is it not true in Ada that if something is a particular type, then
    it has the properties (including alignment) of that type?

This is the terminology point that Robert alluded to.  If something
has an alignment of 64 bits, it *also* has an alignment of 32 bits and
of 16 bits, etc.  So an object that is aligned to 64 bits and is of a
type that is aligned to 32 bits *has* "the properties (including
alignment)" of its type.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Is it not true in Ada that if something is a particular type, then
>     it has the properties (including alignment) of that type?
> 
> This is the terminology point that Robert alluded to.  If something
> has an alignment of 64 bits, it *also* has an alignment of 32 bits and
> of 16 bits, etc.  So an object that is aligned to 64 bits and is of a
> type that is aligned to 32 bits *has* "the properties (including
> alignment)" of its type.

So, what you actually want to do is to set the alignment of the object
to be *more* aligned than its type?  Or, to phrase it another way, you
want the object to be of a type which is more aligned than its
declared type?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> > This means that when compiling the C source that references
> > the variables, I do not know that they are in fact 1-byte
> > aligned.  Do you think the backend should be able to cope
> > with even this scenario, or would you consider this a 
> > frontend bug?

What does it mean "I do not know that they are in fact 1-byte aligned".
All variables (other than bit fields) are 1-byte aligned.

Part of the trouble here is difference in terminology between Ada and
gcc alignment requirements. This has also caused severe unresolved
difficulties when it comes to maximum alignment values.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Robert Dewar wrote:

> What does it mean "I do not know that they are in fact 1-byte aligned".
> All variables (other than bit fields) are 1-byte aligned.

What I meant is, "I do not know that these variables are *not* 
guaranteed to be 2-byte aligned like all others, because for
these variables the front-end has overriden the back-end's
usual minimum 2-byte alignment."

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Robert Dewar]

> I'm not sure whether this is the preferred fix; in particular
> I don't understand why those variables need to have forced 
> alignment in the first place ...


The Ada semantics is that they must have the indicated alignment. It is
of course always fine to give a larger alignment that is a multiple of
the requested alignment (it's just a special case of meeting the alignment
requirement).

We are discussing now exactly what the relation between the Ada semantics
and the gcc semantics for alignment. 

Right now, it looks like the alignment should be forced for subtypes and
not forced for objects, and that is correct provided that objects are always
given an alignment at least as large as that of the subtype.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    Well, it looks like DECL_USER_ALIGN is copied from TYPE_USER_ALIGN
    in do_type_align (stor-layout.c), called via this call chain:

I figured it had to be something like that.  It's probably correct for C,
but not for Ada.  Perhaps we need a new lang hook?

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Well, it looks like DECL_USER_ALIGN is copied from TYPE_USER_ALIGN
>     in do_type_align (stor-layout.c), called via this call chain:
> 
> I figured it had to be something like that.  It's probably correct for C,
> but not for Ada.  Perhaps we need a new lang hook?

Is it not true in Ada that if something is a particular type, then
it has the properties (including alignment) of that type?

That sounds like a pretty fundamental part of the idea of 'type', not
language-specific.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Richard Kenner wrote:

>     Well, it looks like DECL_USER_ALIGN is copied from TYPE_USER_ALIGN
>     in do_type_align (stor-layout.c), called via this call chain:
> 
> I figured it had to be something like that.  It's probably correct for C,
> but not for Ada.  Perhaps we need a new lang hook?

Hmm, this routine was very recently changed by Jason Merrill:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00209.html

I don't quite understand that patch, but it definitely changes
the handling of freshly initialized VAR_DECLs in layout_decl from 

!       DECL_ALIGN (decl) = TYPE_ALIGN (type);
!       DECL_USER_ALIGN (decl) = 0;

to

+       DECL_ALIGN (decl) = TYPE_ALIGN (type);
+       DECL_USER_ALIGN (decl) = TYPE_USER_ALIGN (type);


This certainly explains why I haven't seen the problem earlier ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 10, 2003 at 04:25:31PM -0400, Richard Kenner wrote:
>     Well, it looks like DECL_USER_ALIGN is copied from TYPE_USER_ALIGN
>     in do_type_align (stor-layout.c), called via this call chain:
> 
> I figured it had to be something like that.  It's probably correct for C,
> but not for Ada.  Perhaps we need a new lang hook?

Maybe.  I'm a bit confused as to why *_USER_ALIGN would be set for
"most types" though.  Seems to me that should only be done if the
USER did something specific, like "for x'alignment use N".


r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

After extensive discussion, I think the proper thing is for the Ada
front end to set TYPE_USER_ALIGN on all (or nearly all) types, but
not to set DECL_USER_ALIGN on any decls.  However, when I looked, I see
that is indeed what it *does* do, so I'm now confused about the problem
you are seeing.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Richard Kenner wrote:

> After extensive discussion, I think the proper thing is for the Ada
> front end to set TYPE_USER_ALIGN on all (or nearly all) types, but
> not to set DECL_USER_ALIGN on any decls.  However, when I looked, I see
> that is indeed what it *does* do, so I'm now confused about the problem
> you are seeing.

Well, it looks like DECL_USER_ALIGN is copied from TYPE_USER_ALIGN
in do_type_align (stor-layout.c), called via this call chain:

#0  do_type_align (type=0x100001ff000, decl=0x1000025a680) at ../../gcc-head/gcc/stor-layout.c:369
#1  0x0000000080685996 in layout_decl (decl=0x1000025a680, known_align=0) at ../../gcc-head/gcc/stor-layout.c:429
#2  0x00000000806ae7b8 in build_decl (code=VAR_DECL, name=0x10000258438, type=0x100001ff000) at ../../gcc-head/gcc/tree.c:2428
#3  0x0000000080038a88 in create_var_decl (var_name=0x10000258438, asm_name=0x10000258438, type=0x100001ff000, var_init=0x100001ccb40, const_flag=0,
    public_flag=1, extern_flag=0, static_flag=0, attr_list=0x0) at ../../gcc-head/gcc/ada/utils.c:1290
#4  0x000000008000ae98 in gnat_to_gnu_entity (gnat_entity=1370, gnu_expr=0x100001ccb40, definition=1) at ../../gcc-head/gcc/ada/decl.c:1021
#5  0x0000000080064864 in tree_transform (gnat_node=1376) at ../../gcc-head/gcc/ada/trans.c:773
#6  0x00000000800625b4 in gnat_to_code (gnat_node=1376) at ../../gcc-head/gcc/ada/trans.c:238
#7  0x0000000080075d72 in process_decls (gnat_decls=-99999987, gnat_decls2=0, gnat_end_list=0, pass1p=1, pass2p=1) at ../../gcc-head/gcc/ada/trans.c:4332
#8  0x00000000800712fa in tree_transform (gnat_node=1355) at ../../gcc-head/gcc/ada/trans.c:3229
#9  0x00000000800625b4 in gnat_to_code (gnat_node=1355) at ../../gcc-head/gcc/ada/trans.c:238
#10 0x000000008006256a in gigi (gnat_root=1355, max_gnat_node=1874, number_name=1117, nodes_ptr=0x1000023f010, next_node_ptr=0x100003f7010,
    prev_node_ptr=0x10000428010, elists_ptr=0x80c4f450, elmts_ptr=0x80c4faa0, strings_ptr=0x80cb1c90, string_chars_ptr=0x80cb0900, list_headers_ptr=0x80cd33b0,
    number_units=2, file_info_ptr=0x1ffffffee28 "\021á¦0", standard_integer=42, standard_long_long_float=66, standard_exception_type=1033,
    gigi_operating_mode=0) at ../../gcc-head/gcc/ada/trans.c:221
internal error - unimplemented function unk_lang_create_fundamental_type called.
(looks like my gdb doesn't like Ada ...)

What happens is that build_decl calls make_node (VAR_DECL), which 
returns a node with DECL_ALIGN == 1, and subsequently calls layout_decl,
which calls do_type_align:

static inline void
do_type_align (tree type, tree decl)
{
  if (TYPE_ALIGN (type) > DECL_ALIGN (decl))
    {
      DECL_ALIGN (decl) = TYPE_ALIGN (type);
      DECL_USER_ALIGN (decl) = TYPE_USER_ALIGN (type);
    }
}

and since TYPE_ALIGN is 8 and DECL_ALIGN is 1,
DECL_USER_ALIGN gets set to TYPE_USER_ALIGN (which is set).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    I'm not sure whether this is the preferred fix; in particular
    I don't understand why those variables need to have forced 
    alignment in the first place ...

I think it needs more thought.  Ada semantics on alignment are quite
complex.  At first though, DECL_USER_ALIGN should either *always* be
set or *never* be set, but it's not clear which or even, yet, whether
that's correct or not.

I've started a discussion among the alignment experts in Ada.

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    But this does not solve my problem that Ada does not
    bootstrap; for some reason the Ada frontend sets the
    USER_ALIGN flag for a huge number of variables, even
    those that were defined without any special 'Alignment
    attributes ...

That's because the front end will specify the alignment of some variables.
But what does that have to with failure to bootstrap?

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Richard Kenner wrote:

>     But this does not solve my problem that Ada does not
>     bootstrap; for some reason the Ada frontend sets the
>     USER_ALIGN flag for a huge number of variables, even
>     those that were defined without any special 'Alignment
>     attributes ...
> 
> That's because the front end will specify the alignment of some variables.
> But what does that have to with failure to bootstrap?

Well, as I said, this behaviour of the Ada front end causes
global variables to be generated that have a forced 1-byte
alignment (which up to now never happened with any other
frontend, even though theoretically possible).

Because varasm.c ignores the backend's DATA_ALIGNMENT macro
for variables with forced alignment, this means that labels
end up being generated on odd addresses; the s390 backend
(in 64-bit mode) generates code that assumes this never
happens and will fail if this assumption is violated.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Hello Richard,

I wrote:
>My question is now, why is DATA_ALIGNMENT ignored in such cases?
>Is this a bug or a feature?  If the latter, what other options does
>a backend have to absolutely enforce a minimum alignment for global
>variables?

checking CVS logs showed that this is apparently a feature, 
introduced in a patch of yours a couple of years ago:
http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01037.html
("suppress optional alignment for user variables").

However, the problem remains that on s390, the alignment is not
in fact 'optional' but a hard requirement.  (Looking at the
various implementations of DATA_ALIGNMENT, it seems that mmix
also needs this to be handled as required, while for the others
it is indeed optional.) 

I'm now wondering what we can do to fix this.  One way might
be to add another target macro; or else we could shift the
burden to distinguish between optional and required alignments
into the DATA_ALIGNMENT macro: the macro gets the type as
parameter, and the backend can check whether the USER_ALIGN
is bit is set and if so, only perform mandatory, not optional,
alignment adjustments.

Would you agree with this or do you have other suggestions?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 10, 2003 at 12:40:21AM +0200, Ulrich Weigand wrote:
> However, the problem remains that on s390, the alignment is not
> in fact 'optional' but a hard requirement.  (Looking at the
> various implementations of DATA_ALIGNMENT, it seems that mmix
> also needs this to be handled as required, while for the others
> it is indeed optional.) 

I think I'd prefer that we somehow generate an error for
alignments that cannot be supported (for some definition
of cannot; I have trouble understanding why labels can't
be byte aligned on a byte-addressable machine).

As is clear from the Irix problem you quote, the user 
might have some real need for a particular alignment, 
and forcing something on them may break things.  At least
this way we'll fail to compile instead of DTWT.



r~

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Richard Henderson wrote:

> I think I'd prefer that we somehow generate an error for
> alignments that cannot be supported (for some definition
> of cannot; I have trouble understanding why labels can't
> be byte aligned on a byte-addressable machine).

The problem is the LOAD ADDRESS RELATIVE LONG instruction
which is used to load the address of a label into a register;
this instruction can only load even addresses.  This is
somewhat reasonable as *code* must always be 2-byte aligned
anyway on s390 or execution will trap. 

For data labels, it would of course be possible to use
some other means to load the address (e.g. from the literal
pool); however as the backend has no way to find out for
which labels this would be necessary, the alternative
would mean not to use LARL for any label.

We've decided to simply force 2-byte alignment for all
data labels as well (which can't really hurt anyone),
and then be able to use LARL for all labels.
 
> As is clear from the Irix problem you quote, the user 
> might have some real need for a particular alignment, 
> and forcing something on them may break things.  At least
> this way we'll fail to compile instead of DTWT.

If we want an error message, the safest place to generate
that would probably be the linker (it gets a R_390_PC32DBL 
relocation to an odd address, which cannot be correct).

But this does not solve my problem that Ada does not
bootstrap; for some reason the Ada frontend sets the
USER_ALIGN flag for a huge number of variables, even
those that were defined without any special 'Alignment
attributes ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

I wrote:

> For data labels, it would of course be possible to use
> some other means to load the address (e.g. from the literal
> pool); however as the backend has no way to find out for
> which labels this would be necessary, the alternative
> would mean not to use LARL for any label.

I've tried to identify symbols with forced 1-byte alignment
in encode_section_info, and mark them specically; this allows
me to avoid using LARL for those (and only those) symbols.

The patch below implements this; I'll commit this as soon
as testing is complete, because it fixes a bug in any case.

However, Ada bootstrap still fails, because it uses 
inconsistent alignment flags for the same symbol between
different translation units:  the elaboration check flag
variables are defined from within Ada sources, and marked
as forced 1-byte aligned there, but they are *referenced*
from within auto-generated C sources, and are declared
simply as 'extern char xxx;' there, without any forced
alignment specification.

This means that when compiling the C source that references
the variables, I do not know that they are in fact 1-byte
aligned.  Do you think the backend should be able to cope
with even this scenario, or would you consider this a 
frontend bug?

Bye,
Ulrich

ChangeLog:

	* config/s390/s390.c (larl_operand): Do not allow symbols
	marked with '@'.
	(s390_encode_section_info): Mark symbols with forced 1-byte
	alignment with '@'.
	(s390_strip_name_encoding): Strip '@'.
	(legitimize_pic_address): Handle symbols that are not valid
	LARL operands in 64-bit mode.

Index: gcc/config/s390/s390.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.c,v
retrieving revision 1.86
diff -c -p -r1.86 s390.c
*** gcc/config/s390/s390.c	1 Apr 2003 17:32:33 -0000	1.86
--- gcc/config/s390/s390.c	10 Apr 2003 02:21:28 -0000
*************** larl_operand (op, mode)
*** 1051,1056 ****
--- 1051,1057 ----
    if (GET_CODE (op) == LABEL_REF)
      return 1;
    if (GET_CODE (op) == SYMBOL_REF
+       && XSTR (op, 0)[0] != '@'
        && !tls_symbolic_operand (op)
        && (!flag_pic || SYMBOL_REF_FLAG (op) 
            || CONSTANT_POOL_ADDRESS_P (op)))
*************** larl_operand (op, mode)
*** 1074,1079 ****
--- 1075,1081 ----
    if (GET_CODE (op) == LABEL_REF)
      return 1;
    if (GET_CODE (op) == SYMBOL_REF
+       && XSTR (op, 0)[0] != '@'
        && !tls_symbolic_operand (op)
        && (!flag_pic || SYMBOL_REF_FLAG (op)
            || CONSTANT_POOL_ADDRESS_P (op)))
*************** legitimize_pic_address (orig, reg)
*** 2179,2185 ****
                || CONSTANT_POOL_ADDRESS_P (addr))))
      {
        /* This is a local symbol.  */
!       if (TARGET_64BIT)
          {
            /* Access local symbols PC-relative via LARL.  
               This is the same as in the non-PIC case, so it is 
--- 2181,2187 ----
                || CONSTANT_POOL_ADDRESS_P (addr))))
      {
        /* This is a local symbol.  */
!       if (TARGET_64BIT && larl_operand (addr, VOIDmode))
          {
            /* Access local symbols PC-relative via LARL.  
               This is the same as in the non-PIC case, so it is 
*************** legitimize_pic_address (orig, reg)
*** 2191,2199 ****
  
            rtx temp = reg? reg : gen_reg_rtx (Pmode);
  
!           addr = gen_rtx_UNSPEC (SImode, gen_rtvec (1, addr), 100);
!           addr = gen_rtx_CONST (SImode, addr);
!           addr = force_const_mem (SImode, addr);
  	  emit_move_insn (temp, addr);
  
            base = gen_rtx_REG (Pmode, BASE_REGISTER);
--- 2193,2201 ----
  
            rtx temp = reg? reg : gen_reg_rtx (Pmode);
  
!           addr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), 100);
!           addr = gen_rtx_CONST (Pmode, addr);
!           addr = force_const_mem (Pmode, addr);
  	  emit_move_insn (temp, addr);
  
            base = gen_rtx_REG (Pmode, BASE_REGISTER);
*************** legitimize_pic_address (orig, reg)
*** 2254,2262 ****
  	  if (reload_in_progress || reload_completed)
  	    regs_ever_live[PIC_OFFSET_TABLE_REGNUM] = 1;
  
!           addr = gen_rtx_UNSPEC (SImode, gen_rtvec (1, addr), 112);
!           addr = gen_rtx_CONST (SImode, addr);
!           addr = force_const_mem (SImode, addr);
            emit_move_insn (temp, addr);
  
            new = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, temp);
--- 2256,2264 ----
  	  if (reload_in_progress || reload_completed)
  	    regs_ever_live[PIC_OFFSET_TABLE_REGNUM] = 1;
  
!           addr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), 112);
!           addr = gen_rtx_CONST (Pmode, addr);
!           addr = force_const_mem (Pmode, addr);
            emit_move_insn (temp, addr);
  
            new = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, temp);
*************** legitimize_pic_address (orig, reg)
*** 2282,2288 ****
                    case 100:
                    case 112:
                    case 114:
!                     new = force_const_mem (SImode, orig);
                      break;
  
                    /* @GOTENT is OK as is.  */
--- 2284,2290 ----
                    case 100:
                    case 112:
                    case 114:
!                     new = force_const_mem (Pmode, orig);
                      break;
  
                    /* @GOTENT is OK as is.  */
*************** legitimize_pic_address (orig, reg)
*** 2297,2305 ****
                          rtx temp = reg? reg : gen_reg_rtx (Pmode);
  
                          addr = XVECEXP (addr, 0, 0);
!                         addr = gen_rtx_UNSPEC (SImode, gen_rtvec (1, addr), 114);
!                         addr = gen_rtx_CONST (SImode, addr);
!                         addr = force_const_mem (SImode, addr);
  	                emit_move_insn (temp, addr);
  
                          base = gen_rtx_REG (Pmode, BASE_REGISTER);
--- 2299,2307 ----
                          rtx temp = reg? reg : gen_reg_rtx (Pmode);
  
                          addr = XVECEXP (addr, 0, 0);
!                         addr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), 114);
!                         addr = gen_rtx_CONST (Pmode, addr);
!                         addr = force_const_mem (Pmode, addr);
  	                emit_move_insn (temp, addr);
  
                          base = gen_rtx_REG (Pmode, BASE_REGISTER);
*************** legitimize_pic_address (orig, reg)
*** 2333,2339 ****
                          || CONSTANT_POOL_ADDRESS_P (op0))))
  	      && GET_CODE (op1) == CONST_INT)
  	    {
!               if (TARGET_64BIT)
                  {
                    if (INTVAL (op1) & 1)
                      {
--- 2335,2341 ----
                          || CONSTANT_POOL_ADDRESS_P (op0))))
  	      && GET_CODE (op1) == CONST_INT)
  	    {
!               if (TARGET_64BIT && larl_operand (op0, VOIDmode))
                  {
                    if (INTVAL (op1) & 1)
                      {
*************** legitimize_pic_address (orig, reg)
*** 2370,2379 ****
  
                    rtx temp = reg? reg : gen_reg_rtx (Pmode);
  
!                   addr = gen_rtx_UNSPEC (SImode, gen_rtvec (1, op0), 100);
!                   addr = gen_rtx_PLUS (SImode, addr, op1);
!                   addr = gen_rtx_CONST (SImode, addr);
!                   addr = force_const_mem (SImode, addr);
          	  emit_move_insn (temp, addr);
  
                    base = gen_rtx_REG (Pmode, BASE_REGISTER);
--- 2372,2381 ----
  
                    rtx temp = reg? reg : gen_reg_rtx (Pmode);
  
!                   addr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op0), 100);
!                   addr = gen_rtx_PLUS (Pmode, addr, op1);
!                   addr = gen_rtx_CONST (Pmode, addr);
!                   addr = force_const_mem (Pmode, addr);
          	  emit_move_insn (temp, addr);
  
                    base = gen_rtx_REG (Pmode, BASE_REGISTER);
*************** legitimize_pic_address (orig, reg)
*** 2399,2405 ****
                if (XINT (op0, 1) != 100)
                  abort ();
  
!               new = force_const_mem (SImode, orig);
              }
  
            /* Otherwise, compute the sum.  */
--- 2401,2407 ----
                if (XINT (op0, 1) != 100)
                  abort ();
  
!               new = force_const_mem (Pmode, orig);
              }
  
            /* Otherwise, compute the sum.  */
*************** s390_encode_section_info (decl, first)
*** 6480,6485 ****
--- 6482,6504 ----
  
        XSTR (symbol, 0) = ggc_alloc_string (newstr, len + 2 - 1);
      }
+ 
+   /* If a variable has a forced alignment to < 2 bytes, mark it
+      with '@' to prevent it from being used as LARL operand.  */
+ 
+   else if (TREE_CODE (decl) == VAR_DECL 
+ 	   && DECL_USER_ALIGN (decl) && DECL_ALIGN (decl) < 16
+ 	   && XSTR (symbol, 0)[0] != '@')
+     {
+       const char *symbol_str = XSTR (symbol, 0);
+       size_t len = strlen (symbol_str) + 1;
+       char *newstr = alloca (len + 1);
+ 
+       newstr[0] = '@';
+       memcpy (newstr + 1, symbol_str, len);
+ 
+       XSTR (symbol, 0) = ggc_alloc_string (newstr, len + 1 - 1);
+     }
  }
  
  /* Undo the above when printing symbol names.  */
*************** s390_strip_name_encoding (str)
*** 6490,6495 ****
--- 6509,6516 ----
  {
    if (str[0] == '%')
      str += 2;
+   if (str[0] == '@')
+     str += 1;
    if (str[0] == '*')
      str += 1;
    return str;


-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Geoff Keating]

Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de> writes:

> However, Ada bootstrap still fails, because it uses 
> inconsistent alignment flags for the same symbol between
> different translation units:  the elaboration check flag
> variables are defined from within Ada sources, and marked
> as forced 1-byte aligned there, but they are *referenced*
> from within auto-generated C sources, and are declared
> simply as 'extern char xxx;' there, without any forced
> alignment specification.
> 
> This means that when compiling the C source that references
> the variables, I do not know that they are in fact 1-byte
> aligned.  Do you think the backend should be able to cope
> with even this scenario, or would you consider this a 
> frontend bug?

I'd consider this a bug *somewhere*.  I'd think that if the Ada
frontend is going to do this, then in the C sources the variables need
to be marked with the appropriate alignment.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Geoff Keating wrote:

> I'd consider this a bug *somewhere*.  I'd think that if the Ada
> frontend is going to do this, then in the C sources the variables need
> to be marked with the appropriate alignment.

If I use this patch in addition to the s390 backend fix,
Ada bootstrap goes through on 64-bit:

Index: gcc/ada/bindgen.adb
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ada/bindgen.adb,v
retrieving revision 1.9
diff -c -p -r1.9 bindgen.adb
*** gcc/ada/bindgen.adb	15 Nov 2002 01:45:29 -0000	1.9
--- gcc/ada/bindgen.adb	10 Apr 2003 02:20:56 -0000
*************** package body Bindgen is
*** 485,491 ****
  
           begin
              if U.Set_Elab_Entity then
!                Set_String ("   extern char ");
                 Get_Name_String (U.Uname);
                 Set_Unit_Name;
                 Set_String ("_E;");
--- 485,491 ----
  
           begin
              if U.Set_Elab_Entity then
!                Set_String ("   extern char __attribute__((__aligned__(1))) ");
                 Get_Name_String (U.Uname);
                 Set_Unit_Name;
                 Set_String ("_E;");


I'm not sure whether this is the preferred fix; in particular
I don't understand why those variables need to have forced 
alignment in the first place ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Henderson]

On Thu, Apr 10, 2003 at 05:27:49PM +0200, Ulrich Weigand wrote:
> This means that when compiling the C source that references
> the variables, I do not know that they are in fact 1-byte
> aligned.  Do you think the backend should be able to cope
> with even this scenario, or would you consider this a 
> frontend bug?

I would consider this an Ada bug.


r~

DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Ulrich Weigand]

Hello,

the target macro DATA_ALIGNMENT is supposed to be able to override the
alignment used for global data variables.  We are using this on s390x
to make sure all data objects are at least 2-byte aligned.  This is not
an optimization, but essential for correctness, as we cannot load the
address of a label that is not 2-byte aligned.

Unfortunately, DATA_ALIGNMENT is simply ignored when outputting a
variable that has the DECL_USER_ALIGNMENT flag set.  While this does
not usually occur with C code unless using source code like

  char x __attribute__ ((__aligned__(1)));

this flag is apparently much more frequently set by the Ada frontend.
In fact, this is currently causing bootstrap errors for Ada on s390x
because an elaboration check flag variable is not correctly aligned.


My question is now, why is DATA_ALIGNMENT ignored in such cases?
Is this a bug or a feature?  If the latter, what other options does
a backend have to absolutely enforce a minimum alignment for global
variables?


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com