On alignment

[Jason Merrill <jason at redhat dot com>]

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.