On alignment

[Andrew Haley <aph at redhat dot com>]

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.