Re: On alignment

Re: On alignment

[Robert Dewar]

> That packing rule is part of the i86 psABI

It's still mighty odd, and of course in Ada you have to override this rule
since it conflicts with the Ada standard, which requires that the default
minimum alignment of a composite be not less than the alignment of any
component.

Re: On alignment

[Andrew Haley]

Robert Dewar writes:
 > > That packing rule is part of the i86 psABI
 > 
 > It's still mighty odd, and of course in Ada you have to override this rule
 > since it conflicts with the Ada standard, which requires that the default
 > minimum alignment of a composite be not less than the alignment of any
 > component.

It's pretty weird in C++.  Look at this:


#include <stdio.h>

int
main (int argc, char **argv)
{
  struct { int n; double x; } baz;
  const double &a = baz.x;
  printf ("baz.x align %d\n", __alignof__ baz.x);
  printf ("a align %d\n", __alignof__ a);
  
  return 0;
}


baz.x align 4
a align 8


Andrew.

Re: On alignment

[Jason Merrill]

On Tue, 22 Apr 2003 13:37:43 +0100, Andrew Haley <aph@redhat.com> wrote:

> Robert Dewar writes:
>  > > That packing rule is part of the i86 psABI
>  > 
>  > It's still mighty odd, and of course in Ada you have to override this rule
>  > since it conflicts with the Ada standard, which requires that the default
>  > minimum alignment of a composite be not less than the alignment of any
>  > component.
>
> It's pretty weird in C++.

It's the same in C.  Weird or not, that's what the SVR4 psABI says, so
that's what we do.

Jason

Re: On alignment

[Nicola Pero]

> >  > > That packing rule is part of the i86 psABI
> >  > 
> >  > It's still mighty odd, and of course in Ada you have to override this rule
> >  > since it conflicts with the Ada standard, which requires that the default
> >  > minimum alignment of a composite be not less than the alignment of any
> >  > component.
> >
> > It's pretty weird in C++.
> 
> It's the same in C.  Weird or not, that's what the SVR4 psABI says, so
> that's what we do.

I suspect this is not just weird, but it would have consequences for
Objective-C.

The ObjC runtime library is supposed to be able to compute alignments in
structures at runtime (for various tasks, like encoding / decoding /
forwarding).

At runtime, the ObjC runtime library has information about the struct -
the type of each member.  At the moment, it loops on the struct members,
and uses __alignof__ on each of them to get the alignment of that member
inside the struct (then, can read/write the struct members).  As far as I
understand from this discussion, this doesn't work any longer.

For a typical example, look at libobjc/archive.c, functions
objc_write_type() and objc_read_type().

Assuming that we have to live with this weird ABI thing, what alternative
is there in order to compute alignments inside structs at runtime ?

In other words, how can objc_write_type() and objc_read_type() be
fixed/rewritten in order to work with the weird/unsane ABI thing ?

I don't have time to spend on this issue at the moment, but I thought I'd
raise the issue since it seems you're not aware of it.  I can provide
testcases for objc_write_type() and objc_read_type() if needed.

Re: On alignment

[Andrew Haley]

Jason Merrill writes:
 > On Tue, 22 Apr 2003 13:37:43 +0100, Andrew Haley <aph@redhat.com> wrote:
 > 
 > > Robert Dewar writes:
 > >  > > That packing rule is part of the i86 psABI
 > >  > 
 > >  > It's still mighty odd, and of course in Ada you have to override this rule
 > >  > since it conflicts with the Ada standard, which requires that the default
 > >  > minimum alignment of a composite be not less than the alignment of any
 > >  > component.
 > >
 > > It's pretty weird in C++.
 > 
 > It's the same in C.  Weird or not, that's what the SVR4 psABI says, so
 > that's what we do.

It's rather scary.  It means, for example, that

template<class T> void copy (T *a, T *b)
{
  if (__alignof__ (T) >= 8)
    copy_by_dwords (a, b);
  else
    copy_by_bytes (a, b);
}    

won't do what is expected when applied to a member of a struct.  I
suppose we get away with this because the x86 never generates
alignment traps in such cases.

Andrew.

Re: On alignment

[Andrew Haley]

Nicola Pero writes:
 > 
 > > >  > > That packing rule is part of the i86 psABI
 > > >  > 
 > > >  > It's still mighty odd, and of course in Ada you have to override this rule
 > > >  > since it conflicts with the Ada standard, which requires that the default
 > > >  > minimum alignment of a composite be not less than the alignment of any
 > > >  > component.
 > > >
 > > > It's pretty weird in C++.
 > > 
 > > It's the same in C.  Weird or not, that's what the SVR4 psABI says, so
 > > that's what we do.
 > 
 > I suspect this is not just weird, but it would have consequences
 > for Objective-C.
 > 
 > The ObjC runtime library is supposed to be able to compute
 > alignments in structures at runtime (for various tasks, like
 > encoding / decoding / forwarding).
 > 
 > At runtime, the ObjC runtime library has information about the
 > struct - the type of each member.  At the moment, it loops on the
 > struct members, and uses __alignof__ on each of them to get the
 > alignment of that member inside the struct (then, can read/write
 > the struct members).

That's what we do in gcj, and that is precisely why I raised the
issue.

 > As far as I understand from this discussion, this doesn't work any
 > longer.
 > 
 > For a typical example, look at libobjc/archive.c, functions
 > objc_write_type() and objc_read_type().
 > 
 > Assuming that we have to live with this weird ABI thing, what
 > alternative is there in order to compute alignments inside structs
 > at runtime ?
 > 
 > In other words, how can objc_write_type() and objc_read_type() be
 > fixed/rewritten in order to work with the weird/unsane ABI thing ?

You have to create a struct that contains each base type and look at
its alignment.

Andrew.

Re: On alignment

[Jason Merrill]

On Tue, 22 Apr 2003 17:04:38 +0100 (BST), Nicola Pero <nicola@brainstorm.co.uk> wrote:

> At runtime, the ObjC runtime library has information about the struct -
> the type of each member.  At the moment, it loops on the struct members,
> and uses __alignof__ on each of them to get the alignment of that member
> inside the struct (then, can read/write the struct members).  As far as I
> understand from this discussion, this doesn't work any longer.

If you actually take __alignof the member, this should work fine.  If you
do __alignof the type, you will get the larger number.

On Tue, 22 Apr 2003 17:19:28 +0100, Andrew Haley <aph@redhat.com> wrote:

> It's rather scary.  It means, for example, that
>
> template<class T> void copy (T *a, T *b)
> {
>   if (__alignof__ (T) >= 8)
>     copy_by_dwords (a, b);
>   else
>     copy_by_bytes (a, b);
> }    
>
> won't do what is expected when applied to a member of a struct.  I
> suppose we get away with this because the x86 never generates
> alignment traps in such cases.

Exactly.  A STRICT_ALIGNMENT target wouldn't do this sort of thing.

Jason

Re: On alignment

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| On 02 May 2003 15:07:54 +0200, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Tom Tromey <tromey@redhat.com> writes:
| >
| > [...]
| >
| > | What will eventually go wrong with what we have now?
| > | 
| > |     template<typename T>
| > |     struct aligner
| > |     {
| > |       T field;
| > |     };
| > | 
| > |     #define ALIGNOF(TYPE) (__alignof__ (((aligner<TYPE> *) 0)->field))
| >
| > This, as I understand it from my previous attempt, won't give you the
| > right answer (for double, it would give 8 instead of 4).
| 
| It will give you the right answer on the trunk (and I just checked in a
| patch so it will give you the right answer in 3.3 as well).

OK, many thanks.

-- Gaby

Re: On alignment

[Jason Merrill]

On 02 May 2003 15:07:54 +0200, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Tom Tromey <tromey@redhat.com> writes:
>
> [...]
>
> | What will eventually go wrong with what we have now?
> | 
> |     template<typename T>
> |     struct aligner
> |     {
> |       T field;
> |     };
> | 
> |     #define ALIGNOF(TYPE) (__alignof__ (((aligner<TYPE> *) 0)->field))
>
> This, as I understand it from my previous attempt, won't give you the
> right answer (for double, it would give 8 instead of 4).

It will give you the right answer on the trunk (and I just checked in a
patch so it will give you the right answer in 3.3 as well).

> What is wrong with the following code I posted earlier?
>
>     template<typename T>
>       struct alignment {
>
>          struct helper {
>             T datum;
>             helper();
>          };
>
>          static helper instance;
>
>          enum { value = __alignof__ (instance) };
>       };

The alignment of a non-field instance of a class can be greater that the
alignment of the class itself.  Just saying __alignof (helper) should work,
though I'm not sure it's guaranteed to work.  Also, why do you give helper
a constructor?

Tom's example above is directly asking the question they want an answer to;
as long as it works, that's the best way to do it, and it does work now.

Jason

Re: On alignment

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

[...]

| What will eventually go wrong with what we have now?
| 
|     template<typename T>
|     struct aligner
|     {
|       T field;
|     };
| 
|     #define ALIGNOF(TYPE) (__alignof__ (((aligner<TYPE> *) 0)->field))

This, as I understand it from my previous attempt, won't give you the
right answer (for double, it would give 8 instead of 4).

What is wrong with the following code I posted earlier?

    template<typename T>
      struct alignment {

         struct helper {
            T datum;
            helper();
         };

         static helper instance;

         enum { value = __alignof__ (instance) };
      };

-- Gaby

Re: On alignment

[Tom Tromey]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Jason> A similar trick using offsetof should work with all versions of
Jason> gcc; just add a char field to the beginning of the struct, and
Jason> measure the offset to the TYPE field.

Andrew> Ah, okay.  That sounds pretty neat.

Andrew> Tom, time for the third (or is it fourth) version of your patch.  :-)

How will this work?  We can't do this:

    template<typename T>
    struct aligner
    {
      char dummy;
      T field;
    }

A plain offsetof(aligner<jbyte>, field) will yield the wrong answer (2
instead of 1).  I guess one answer would be "don't bother with byte or
boolean".


What will eventually go wrong with what we have now?

    template<typename T>
    struct aligner
    {
      T field;
    };

    #define ALIGNOF(TYPE) (__alignof__ (((aligner<TYPE> *) 0)->field))

Tom

Re: On alignment

[Andrew Haley]

Jason Merrill writes:
 > 
 > A similar trick using offsetof should work with all versions of
 > gcc; just add a char field to the beginning of the struct, and
 > measure the offset to the TYPE field.

Ah, okay.  That sounds pretty neat.

Tom, time for the third (or is it fourth) version of your patch.  :-)

Andrew.

Re: On alignment

[Jason Merrill]

On 23 Apr 2003 13:39:49 -0600, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> Gabriel> #define FIELD_ALIGNOF(TYPE) __alignof (((struct { TYPE t; } *)0)->t)
>
> Gabriel>     j.C: In function `int main()':
> Gabriel>     j.C:7: error: types may not be defined in casts

Ah, yes.  I was using a C testcase.

> In that message you said that you got "8" as the answer for a double
> field on x86.  That's not the answer I'm looking for :-(.  On x86, a
> double field has alignment 4, while a non-field double has alignment 8.
> In the libgcj context, we're only ever laying out structures, so we need
> to get "4" as the answer.  The above does do that.

Again, this currently only works in the trunk.

A similar trick using offsetof should work with all versions of gcc; just
add a char field to the beginning of the struct, and measure the offset to
the TYPE field.

Jason

Re: On alignment

[Jamie Lokier]

Tom Tromey wrote:
>     struct aligner { double field; };
>     int compute () { return __alignof__ (aligner::field); }
> 
> I can use __alignof__(aligner), but my concern is that eventually this
> will yield "8" instead of "4" on x86.

When __alignof__(aligner) returns 8, you may find that
__alignof__(((aligner *)0)->field) returns 8 also.  The __alignof__
operator on a structure field doesn't report "alignment for structure
layout purposes", it reports "alignment of this object (the field) in
memory", which would be 8.  Think about it.

-- Jamie

Re: On alignment

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

[...]

| Gabriel> I think the template-based solution I posted in another
| Gabriel> message solves the problem...
| 
| In that message you said that you got "8" as the answer for a double
| field on x86.  That's not the answer I'm looking for :-(.  On x86, a
| double field has alignment 4, while a non-field double has alignment
| 8. 

Thank you for correcting me; it seems like I made two errors in my
previous post:

  1) I took the __alignof__ of the field instead of the instance
  2) I used a reference (I can't remember why I wrote that).

They are corrected now in this:

    template<typename T>
      struct object_alignment {

         struct helper {
            T datum;
            helper();
         };

         static helper instance;

         enum { value = __alignof__ (instance) };
      };

and now, I get the expected answer (4).  [I would appreciate you
double check]

Thanks,

-- Gaby

Re: On alignment

[Tom Tromey]

>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

Gabriel> #define FIELD_ALIGNOF(TYPE) __alignof (((struct { TYPE t; } *)0)->t)

Gabriel>     j.C: In function `int main()':
Gabriel>     j.C:7: error: types may not be defined in casts

I got that too, but I worked around it like so:

template<typename T>
struct aligner
{
  T field;
};

#define ALIGNOF(TYPE) (__alignof__ (((aligner<TYPE> *) 0)->field))


Gabriel> I think the template-based solution I posted in another
Gabriel> message solves the problem...

In that message you said that you got "8" as the answer for a double
field on x86.  That's not the answer I'm looking for :-(.  On x86, a
double field has alignment 4, while a non-field double has alignment
8.  In the libgcj context, we're only ever laying out structures, so
we need to get "4" as the answer.  The above does do that.

Tom

Re: On alignment

[Robert Dewar]

> Well, what about struct bar { double x; int y; double z; } ?
> giving it an alignment of 8 doesn't improve things, as one double will
> always be misaligned.  OTOH it is odd to have a lower alignment for
> bar than for foo, even though the start of bar has the same structure
> as the entirety of foo.

Yes, but so what, just because you can find an example where you can't
improve things is no reason not to improve things when you can :-)

Re: On alignment

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| On 23 Apr 2003 12:11:24 -0600, Tom Tromey <tromey@redhat.com> wrote:
| 
| >>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
| >
| > [ about  struct foo { double x; } ]
| >
| > Tom> I'd like to find the most future-proof way to do this.  In the above,
| > Tom> is __alignof__(foo::x) the best way?  I'm only concerned with
| > Tom> alignment of fields.
| >
| > Jason> It is since my recent patch to do all alignment calculation for
| > Jason> fields in layout_decl.
| >
| > I can't do this.
| >
| >     struct aligner { double field; };
| >
| >     int compute () { return __alignof__ (aligner::field); }
| 
| Ah, no, you need to do something like
| 
| #define FIELD_ALIGNOF(TYPE) __alignof (((struct { TYPE t; } *)0)->t)

Hmm, when tested like

    #include <iostream>

    #define FIELD_ALIGNOF(TYPE) __alignof (((struct { TYPE t; } *)0)->t)

    int main()
    {
       std::cout << FIELD_ALIGNOF(double) << std::endl;
    }

I get:

    j.C: In function `int main()':
    j.C:7: error: types may not be defined in casts

I think the template-based solution I posted in another message solves
the problem...  

-- Gaby
 

Re: On alignment

[Joern Rennecke]

> For the same reason, "struct foo { double x; }" as a standalone
> variable should have alignment 8, not 4.  Andrew's test shows it has
> an alignment of 4.

Well, what about struct bar { double x; int y; double z; } ?
giving it an alignment of 8 doesn't improve things, as one double will
always be misaligned.  OTOH it is odd to have a lower alignment for
bar than for foo, even though the start of bar has the same structure
as the entirety of foo.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: On alignment

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

| >>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
| 
| [ about  struct foo { double x; } ]
| 
| Tom> I'd like to find the most future-proof way to do this.  In the above,
| Tom> is __alignof__(foo::x) the best way?  I'm only concerned with
| Tom> alignment of fields.
| 
| Jason> It is since my recent patch to do all alignment calculation for
| Jason> fields in layout_decl.
| 
| I can't do this.
| 
|     struct aligner { double field; };
| 
|     int compute () { return __alignof__ (aligner::field); }
| 
| fleche. gcc -c y.cc
| y.cc: In function `int compute()':
| y.cc:1: error: invalid use of non-static data member `aligner::field'
| y.cc:3: error: from this location

The following does the job:

    template<typename T>
      struct object_alignment {

         struct helper {
            T& datum;
            helper();
         };

         static helper instance;

         enum { value = __alignof__ (instance.datum) };
      };

To be used as object_alignment<T>::value.

| I can use __alignof__(aligner), but my concern is that eventually this
| will yield "8" instead of "4" on x86.

With the above, the following

     #include <iostream>

     int main()
     {
        std::cout << object_alignment<double>::value
                  << std::endl;
     }

outputs "8" on an i686-pc-linux-gnu.

Enjoy ;-)

-- Gaby

Re: On alignment

[Jason Merrill]

On 23 Apr 2003 12:11:24 -0600, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
>
> [ about  struct foo { double x; } ]
>
> Tom> I'd like to find the most future-proof way to do this.  In the above,
> Tom> is __alignof__(foo::x) the best way?  I'm only concerned with
> Tom> alignment of fields.
>
> Jason> It is since my recent patch to do all alignment calculation for
> Jason> fields in layout_decl.
>
> I can't do this.
>
>     struct aligner { double field; };
>
>     int compute () { return __alignof__ (aligner::field); }

Ah, no, you need to do something like

#define FIELD_ALIGNOF(TYPE) __alignof (((struct { TYPE t; } *)0)->t)

Jason

Re: On alignment

[Tom Tromey]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

[ about  struct foo { double x; } ]

Tom> I'd like to find the most future-proof way to do this.  In the above,
Tom> is __alignof__(foo::x) the best way?  I'm only concerned with
Tom> alignment of fields.

Jason> It is since my recent patch to do all alignment calculation for
Jason> fields in layout_decl.

I can't do this.

    struct aligner { double field; };

    int compute () { return __alignof__ (aligner::field); }

fleche. gcc -c y.cc
y.cc: In function `int compute()':
y.cc:1: error: invalid use of non-static data member `aligner::field'
y.cc:3: error: from this location


I can use __alignof__(aligner), but my concern is that eventually this
will yield "8" instead of "4" on x86.  libgcj really needs to know the
alignment required in structures, for compatibility with the compiler.
Preferably we'd have the compiler tell us this info.

Tom

Re: On alignment

[Jason Merrill]

On 23 Apr 2003 10:00:22 -0600, Tom Tromey <tromey@redhat.com> wrote:

> I'd like to find the most future-proof way to do this.  In the above,
> is __alignof__(foo::x) the best way?  I'm only concerned with
> alignment of fields.

It is since my recent patch to do all alignment calculation for fields in
layout_decl.  Unfortunately, previous releases gave the wrong answer, and I
haven't moved that patch into 3.3.  It should be possible to fix this more
simply in 3.3 by adding

 DECL_ALIGN (field) = desired_align;

to the end of update_alignment_for_field.

Jason

Re: On alignment

[Tom Tromey]

>>>>> "Jamie" == Jamie Lokier <jamie@shareable.org> writes:

Jamie> For the same reason, "struct foo { double x; }" as a standalone
Jamie> variable should have alignment 8, not 4.  Andrew's test shows
Jamie> it has an alignment of 4.

In libgcj we need to find the alignment of things so that the
interpreter can compatibly lay out structures it creates.  In the past
we didn't worry much about this, since compiled code couldn't observe
interpreted classes, but it is becoming a problem now.

I'd like to find the most future-proof way to do this.  In the above,
is __alignof__(foo::x) the best way?  I'm only concerned with
alignment of fields.

Tom

Re: On alignment

[Jason Merrill]

On Wed, 23 Apr 2003 13:49:44 +0100, Jamie Lokier <jamie@shareable.org> wrote:

> For the same reason, "struct foo { double x; }" as a standalone variable
> should have alignment 8, not 4.  Andrew's test shows it has an alignment
> of 4.

Yes, that would be a reasonable thing to do.  It just needs someone to
implement it.

Jason

Re: On alignment

[Jamie Lokier]

Andreas Schwab wrote:
> Andrew Haley <aph@redhat.com> writes:
> |> WHat I still cannot understand is why a struct that contains a double
> |> is 4-aligned on x86, but a double is 8-aligned.  This means that you
> |> cannot infer the alignment of a struct from the alignment of its
> |> members.  Is this really part of the multi-vendor ABI?
> 
> The alignment of a struct member determines the amount of padding that
> must be inserted, thus it is important to maintain the exact alignment
> requirements of the ABI.  For simple variables there is no such
> requirement, there is never a problem when a standalone variable is
> overaligned.

For the same reason, "struct foo { double x; }" as a standalone
variable should have alignment 8, not 4.  Andrew's test shows it has
an alignment of 4.

Exactly like "double", "struct foo" should have size and alignment 8,
but when it's a field in a larger structure it should pack with alignment 4.

-- Jamie

Re: On alignment

[Robert Dewar]

> It's the same in C.  Weird or not, that's what the SVR4 psABI says, so
> that's what we do.

Of course this is an excellent example of a case where for stand alone
objects of the type, the alignment should be increased to get efficient
execution. This increase for stand alone objects of course is compatibole
with the SVR4 ABI.

Re: On alignment

[Andreas Schwab]

Andrew Haley <aph@redhat.com> writes:

|> WHat I still cannot understand is why a struct that contains a double
|> is 4-aligned on x86, but a double is 8-aligned.  This means that you
|> cannot infer the alignment of a struct from the alignment of its
|> members.  Is this really part of the multi-vendor ABI?

The alignment of a struct member determines the amount of padding that
must be inserted, thus it is important to maintain the exact alignment
requirements of the ABI.  For simple variables there is no such
requirement, there is never a problem when a standalone variable is
overaligned.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: On alignment

[Andrew Haley]

Nathan Sidwell writes:
 > Andrew Haley wrote:
 > > WHat I still cannot understand is why a struct that contains a double
 > > is 4-aligned on x86, but a double is 8-aligned.  This means that you
 > > cannot infer the alignment of a struct from the alignment of its
 > > members.  Is this really part of the multi-vendor ABI?
 > That packing rule is part of the i86 psABI

Thanks.  Got a link to that?

Andrew.

Re: On alignment

[Nathan Sidwell]

Andrew Haley wrote:
> WHat I still cannot understand is why a struct that contains a double
> is 4-aligned on x86, but a double is 8-aligned.  This means that you
> cannot infer the alignment of a struct from the alignment of its
> members.  Is this really part of the multi-vendor ABI?
That packing rule is part of the i86 psABI

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: On alignment

[Andrew Haley]

WHat I still cannot understand is why a struct that contains a double
is 4-aligned on x86, but a double is 8-aligned.  This means that you
cannot infer the alignment of a struct from the alignment of its
members.  Is this really part of the multi-vendor ABI?

Andrew.


#include <stdio.h>

int
main (int argc, char **argv)
{
  typedef struct foo { double x; } foo;
  foo bar;
  printf ("double align %d size %d\n", __alignof__(double), sizeof(double));
  printf ("foo align %d size %d\n", __alignof__(foo), sizeof(foo));
  
  return 0;
}

Re: On alignment

[Mark Mitchell]

> In the future, we need to be using the same layout code as C++.  In
> fact I thought we *were*, so I didn't expect any of this.  I assumed
> that when C++ moved to the new ABI gcj would automatically follow,
> because we were using the same code.  I didn't realize that the C++
> guys would make the changes inside their front end.

To be clear, C++ has *always* done stuff in the front end.  The new ABI
work changed what we did, but not where we did it.

In fact, my (relatively) recent changes for handling "subobject"
versions of classes actually bring things closer to just using the
middle-end layout code.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: On alignment

[Andrew Haley]

Tom Tromey writes:
 > >>>>> "Kevin" == Kevin B Hendricks <kevin.hendricks@sympatico.ca> writes:
 > 
 > Kevin> Will having long long int aligned to 8 and double aligned to 4
 > Kevin> create any problems for gcj if a similar alignment macro is
 > Kevin> used for gcj given that doubles and long long int are
 > Kevin> different?
 > 
 > I'm not certain.  My understanding is that g++ does all the field
 > alignment in the front end,

Not entirely, I don't think.  It's a mixture of both, which is AFAIK
the source of these problems.

 > while gcj completely relies on stor-layout to do it.  So the
 > question is whether g++ (with whatever hack we're adding to the
 > generated headers) and stor-layout agree in the above scenario.

With the C++ layout bugs fixed, I expect this will be fine.

In the future, we need to be using the same layout code as C++.  In
fact I thought we *were*, so I didn't expect any of this.  I assumed
that when C++ moved to the new ABI gcj would automatically follow,
because we were using the same code.  I didn't realize that the C++
guys would make the changes inside their front end.

Andrew.

Re: On alignment

[Tom Tromey]

>>>>> "Kevin" == Kevin B Hendricks <kevin.hendricks@sympatico.ca> writes:

Kevin> Will having long long int aligned to 8 and double aligned to 4
Kevin> create any problems for gcj if a similar alignment macro is
Kevin> used for gcj given that doubles and long long int are
Kevin> different?

I'm not certain.  My understanding is that g++ does all the field
alignment in the front end, while gcj completely relies on stor-layout
to do it.  So the question is whether g++ (with whatever hack we're
adding to the generated headers) and stor-layout agree in the above
scenario.

Tom

Re: On alignment

[Jason Merrill]

On Tue, 25 Mar 2003 13:44:59 -0500, "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca> wrote:

> Also, this is why Darwin gcc3 alignment (and AIX it seems from David))
> which has double aligned to 4 and long long int aligned to 8 throws off
> some of the OOo alignment tricks as well.

Well, that's wacky.  Yes, that would cause trouble, as the assumption that
a double field already has maximum field alignment is no longer valid.  So
with a testcase like

struct A {
  A();
  long long i;
  double d;
};

struct B:A {
  double bd;
};

you would need the alignment hack to increase the alignment of bd to 8.
But if A doesn't have alignment of 8, applying the alignment hack would
incorrectly increase the alignment of bd (because of the bug).  OK, I think
we really need to fix this for 3.3.

Jason

Re: On alignment

[Kevin B. Hendricks]

Hi,

> Sounds like they noticed and worked around this bug.  Which makes me more
> inclined to go ahead and fix it.

Yes they did. 

Also,  this is why Darwin gcc3 alignment (and AIX it seems from David)) 
which has double aligned to 4 and long long int aligned to 8 throws off 
some of the OOo alignment tricks as well.

Will having long long int aligned to 8 and double aligned to 4 create any 
problems for gcj if a similar alignment macro is used for gcj given that 
doubles and long long int are different ?  Or am I off in the weeds here 
in my understanding  ... I often get confused by alignment of structures, 
size of structures, and the alignment and size of their largest member?

Kevin
 

Re: On alignment

[Tom Tromey]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

Jason> Perhaps we should add an attribute to suppress the base padding
Jason> optimization so that people don't have to jump through these hoops.

I think for Java the hoops are a temporary thing.  It would make sense
for us to do the base padding optimization.  We just happened to find
this at the wrong time of the development cycle, so we need a quick
fix.

Tom

Re: On alignment

[Jason Merrill]

On Tue, 25 Mar 2003 13:27:08 -0500, Jason Merrill <jason@redhat.com> wrote:

> On Tue, 25 Mar 2003 11:22:13 -0500, "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca> wrote:
>
>> If I am not mistaken, a similar approach was used by OpenOffice.org when trying to support 
>> both gcc 2.9.5X components and gcc 3.X components 
>
> Indeed, it looks like they're trying to do the same thing using the same
> technique that Andrew was.  Can anyone tell me whether they applied
> CPPU_GCC3_ALIGN to any long long or double fields?

The comment would appear to suggest otherwise:

// This pragma macro is appended to every first member of a struct, 
// iff the struct inherits from a base struct and the first member
// of this structure  is not a double or [unsigned] long long.

Sounds like they noticed and worked around this bug.  Which makes me more
inclined to go ahead and fix it.

Jason

Re: On alignment

[Jason Merrill]

On Tue, 25 Mar 2003 11:22:13 -0500, "Kevin B. Hendricks" <kevin.hendricks@sympatico.ca> wrote:

> If I am not mistaken, a similar approach was used by OpenOffice.org when trying to support 
> both gcc 2.9.5X components and gcc 3.X components 

Indeed, it looks like they're trying to do the same thing using the same
technique that Andrew was.  Can anyone tell me whether they applied
CPPU_GCC3_ALIGN to any long long or double fields?  Doing so would fail to
achieve the goal of compatibility with 2.95 compilers due to the bug under
discussion.

Perhaps we should add an attribute to suppress the base padding
optimization so that people don't have to jump through these hoops.

Jason

Re: On alignment

[Kevin B. Hendricks]

Hi,
 
 >   struct B : A {
 >     // force normal alignment
 >     char : 0 __attribute ((__aligned (__alignof (A))));
 >     short bs;
 >   };

FWIW: 

If I am not mistaken, a similar approach was used by OpenOffice.org when trying to support 
both gcc 2.9.5X components and gcc 3.X components 

Here is a piece of the cppu component test code:

#define CPPU_GCC3_ALIGN( base_struct ) __attribute__ ((aligned (__alignof__ (base_struct))))

struct C1
{
    signed short n1;
};

struct C2 : public C1
{
    signed long n2 CPPU_GCC3_ALIGN( C1 );
};

...

struct M
{
        signed long     n;
        signed short    o;
};

struct N : public M
{
        signed short    p CPPU_GCC3_ALIGN( M );
};

Kevin

Re: On alignment

[Andrew Haley]

Jason Merrill writes:
 > On Sat, 22 Mar 2003 09:12:32 +0000 (GMT), Andrew Haley <aph@redhat.com> wrote:
 > 
 > > Jason Merrill writes:
 > >  > Can you give me an example of a case that needs an aligned attribute?  What
 > >  > is the Java frontend doing that makes this necessary?
 > >
 > > http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00429.html
 > 
 > OK, you're trying to suppress the tail padding optimization.  It occurred
 > to me that another way to express that could be
 > 
 >   struct B : A {
 >     // force normal alignment
 >     char : 0 __attribute ((__aligned (__alignof (A))));
 >     short bs;
 >   };
 > 
 > but of course that doesn't work properly either; user-specified
 > alignment is currently ignored on a zero-length bitfield.  But
 > that's a one-line fix, and shouldn't create a compatibility
 > problem, since there would have been no point in specifying such an
 > alignment before.  Would that work for you?

Excellent.  That's all I need.

Andrew.

Re: On alignment

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Sat, 22 Mar 2003 09:12:32 +0000 (GMT), Andrew Haley <aph@redhat.com> wrote:

> Jason Merrill writes:
>  > Can you give me an example of a case that needs an aligned attribute?  What
>  > is the Java frontend doing that makes this necessary?
>
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00429.html

OK, you're trying to suppress the tail padding optimization.  It occurred
to me that another way to express that could be

  struct B : A {
    // force normal alignment
    char : 0 __attribute ((__aligned (__alignof (A))));
    short bs;
  };

but of course that doesn't work properly either; user-specified alignment
is currently ignored on a zero-length bitfield.  But that's a one-line fix,
and shouldn't create a compatibility problem, since there would have been
no point in specifying such an alignment before.  Would that work for you?

We may well still want to fix the other bugs, but perhaps not in 3.3.  I'm
still interested in other opinions.

Jason


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 768 bytes --]

*** stor-layout.c.~1~	2003-01-26 04:02:25.000000000 -0500
--- stor-layout.c	2003-03-24 19:26:55.000000000 -0500
*************** update_alignment_for_field (rli, field, 
*** 758,764 ****
  	 within the structure.  */
        if (! integer_zerop (DECL_SIZE (field)))
  	rli->record_align = MAX (rli->record_align, desired_align);
!       else if (! DECL_PACKED (field))
  	desired_align = TYPE_ALIGN (type);
  
        /* A named bit field of declared type `int'
--- 758,764 ----
  	 within the structure.  */
        if (! integer_zerop (DECL_SIZE (field)))
  	rli->record_align = MAX (rli->record_align, desired_align);
!       else if (! DECL_PACKED (field) && !user_align)
  	desired_align = TYPE_ALIGN (type);
  
        /* A named bit field of declared type `int'

Re: On alignment

[Andrew Haley]

Jason Merrill writes:
 > Can you give me an example of a case that needs an aligned attribute?  What
 > is the Java frontend doing that makes this necessary?

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00429.html
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00432.html

Andrew.

Re: On alignment

[Tom Tromey]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

Jason> Can you give me an example of a case that needs an aligned
Jason> attribute?  What is the Java frontend doing that makes this
Jason> necessary?

I haven't looked at this part of the gcj front end, so Andrew would
have to answer that part.

I do have a couple test cases that show the problems.  Basically they
are areas where gcj and g++ disagree about object layout.  I've
checked them in on the trunk, under libjava/testsuite/libjava.cni.

Tom

Re: On alignment

[Jason Merrill]

Can you give me an example of a case that needs an aligned attribute?  What
is the Java frontend doing that makes this necessary?

Jason

Re: On alignment

[Tom Tromey]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> Unless we can achieve layout compatibility between Java and
Andrew> C++ code we will not be able to ship gcj.

Yes -- we need either a fix in g++ or a fix in gcj or a workaround
somewhere (gcjh perhaps).

PR 10145 tracks this problem.

Tom

Re: On alignment

[Andrew Haley]

Michael Matz writes:

 > On Thu, 20 Mar 2003, Jason Merrill wrote:
 > 
 > > Do people think this bug is worth fixing?  The behavior is rather
 > > surprising, but changing it might break binary compatibility for affected
 > > code--of which there's not likely to be very much, but there could be some.
 > > Code which really wants, say, aligment of 4 for long long could say
 > > __attribute__ ((packed, aligned (4))).  On the other hand, the change would
 > > restore binary compatibility with 2.95 for C code.
 > 
 > This would change e.g the layout of things like:
 > 
 > struct A { int i; };
 > struct B { struct A a; long long int __attribute__((aligned(4))) li; };
 > struct C { struct B b; int j; };
 > 
 > , right?  If yes I think there is not exactly few code which would be
 > broken binary compatibility wise.  I've seen strange things for instance
 > in OpenOffice, where they play with alignments.  And to this end
 > compatibility with 3.x matters more that with 2.95.x.

Well, yes.  But code which reasonably expects a field with alignof == 8 
to be 8-aligned is broken at the present time.

Andrew.

Re: On alignment

[Michael Matz]

Hi,

On Thu, 20 Mar 2003, Jason Merrill wrote:

> Do people think this bug is worth fixing?  The behavior is rather
> surprising, but changing it might break binary compatibility for affected
> code--of which there's not likely to be very much, but there could be some.
> Code which really wants, say, aligment of 4 for long long could say
> __attribute__ ((packed, aligned (4))).  On the other hand, the change would
> restore binary compatibility with 2.95 for C code.

This would change e.g the layout of things like:

struct A { int i; };
struct B { struct A a; long long int __attribute__((aligned(4))) li; };
struct C { struct B b; int j; };

, right?  If yes I think there is not exactly few code which would be
broken binary compatibility wise.  I've seen strange things for instance
in OpenOffice, where they play with alignments.  And to this end
compatibility with 3.x matters more that with 2.95.x.


Ciao,
Michael.

On alignment

[Andrew Haley]

I've beeen playing with this in an attempt to find a workaround, and
it's such a mess that I don't think it's worth it.

Consider this:

---------------------------------------------------------------------
#include <stdio.h>

class Boof
{
  int arse ()
  {
    return 25;
  }

  void *prickle;
};

class foo : Boof
{
  public: long long i;
};


int main ()
{
  foo f;
  fprintf(stderr, "offset: %d\n", (char *)&f.i - (char *)&f);
  fprintf(stderr, "alignof: %d\n", __alignof__(f.i ));
  return 0;
}
---------------------------------------------------------------------

Run it on x86, and you get:

offset: 4
alignof: 8

We can't leave it like this.

Andrew.

On alignment

[Andrew Haley]

Jason Merrill writes:
 > Andrew Haley recently pointed me at an alignment bug:
 > 
 >   http://gcc.gnu.org/ml/gcc/2003-03/msg01196.html
 > 
 > Here, the presence of an aligned attribute is giving the field alignment of
 > 8, even though only 4 was requested.  This worked in 2.95, but has been
 > broken in all 3.x releases (i.e. since Jakub's *_USER_ALIGN changes).
 > 
 > This happens because DECL_USER_ALIGN overrides
 > BIGGEST_FIELD_ALIGNMENT.  The right way to handle this is to clear
 > DECL_USER_ALIGN when rounding up DECL_ALIGN to TYPE_ALIGN; the code
 > in layout_decl gets this right, but check_field_decl in the C++
 > frontend and finish_struct in the C frontend get it wrong.
 > 
 > Do people think this bug is worth fixing?  The behavior is rather
 > surprising, but changing it might break binary compatibility for
 > affected code--of which there's not likely to be very much, but
 > there could be some.  Code which really wants, say, aligment of 4
 > for long long could say __attribute__ ((packed, aligned (4))).  On
 > the other hand, the change would restore binary compatibility with
 > 2.95 for C code.

__attribute__ ((packed, aligned (4))) doesn't work for me. 

I need to be able to supply an alignment that will increase the
alignment of an object if and only if the supplied alignment is
greater than the natural alignment of that object.  

The problem is that gcjh, which generates C++ compatible header files,
knows nothing about the alignment of fields.  For example, It cannot
spit out aligned (4) because it doesn't know what the alignment of a
field should be.  gcjh can, however, spit out

       jlong __attribute__ ((aligned (alignof (classX)))) foo;

in order to produce a field that is effectively

       jlong __attribute__ ((aligned (MAX(alignof (classX), alignof (jlong))))) foo;

This is what the documentation for aligned() says it should do.

Unless we can achieve layout compatibility between Java and C++ code
we will not be able to ship gcj.

I know of no other way to solve this problem unless gcjh is made
cognizant of the target machine, which IMO would be to burden a simple
application for insufficient reason.  It would also be a lot of work.

If we really need to preserve binary compatibility we could have
another attribute -- one which follows the spec for aligned() -- that
is for gcc internal use only.  gcjh could use that instead of
aligned().

Andrew.

On alignment

[Jason Merrill]

Andrew Haley recently pointed me at an alignment bug:

  http://gcc.gnu.org/ml/gcc/2003-03/msg01196.html

Here, the presence of an aligned attribute is giving the field alignment of
8, even though only 4 was requested.  This worked in 2.95, but has been
broken in all 3.x releases (i.e. since Jakub's *_USER_ALIGN changes).

This happens because DECL_USER_ALIGN overrides BIGGEST_FIELD_ALIGNMENT.
The right way to handle this is to clear DECL_USER_ALIGN when rounding up
DECL_ALIGN to TYPE_ALIGN; the code in layout_decl gets this right, but
check_field_decl in the C++ frontend and finish_struct in the C frontend
get it wrong.

Do people think this bug is worth fixing?  The behavior is rather
surprising, but changing it might break binary compatibility for affected
code--of which there's not likely to be very much, but there could be some.
Code which really wants, say, aligment of 4 for long long could say
__attribute__ ((packed, aligned (4))).  On the other hand, the change would
restore binary compatibility with 2.95 for C code.

Jason

Asides: it seems to me that there's no reason for the frontends to be
messing with this sort of thing without a good reason; record layout should
be handled in stor-layout.c as much as possible.  Most of the existing code
in the C and C++ frontends that touch DECL_ALIGN is redundant.

Also, I noticed that EMPTY_FIELD_BOUNDARY is only handled in the frontend,
and that it is ignored on targets which define PCC_BITFIELD_TYPE_MATTERS,
though that is not made clear in tm.texi.  I plan to clean these bits up
while I'm looking at this stuff.