PATCH: Change C ABI (!) on PCC_BITFIELD_TYPE_MATTERS machines

[Mark Mitchell <mark at codesourcery dot com>]

I have not yet checked this patch in, but I plan to do so shortly.  I
think it will be non-controversial, but if it is I will back it out
if it turns out to be more controversial than I expect.

On PCC_BITFIELD_TYPE_MATTERS machines, a structure like:

  struct {
    int : 32;
  };

ended up with 4-byte alignment.

This is not correct, with respect to the psABI for IA32, Itanium,
x86-64, SPARC, or MIPS, which are all architectures for which we
define PCC_BITFIELD_TYPE_MATTERS.  Those psABIs all indicate that
unnamed bit-fields do not affect structure alignment.  I could not
locate any psABIs for machines which define PCC_BITFIELD_TYPE_MATTERS
that indicate the unnamed bit-fields do affect alignment.

I've verified that other compilers (such as Intel's IA32 compiler)
respect the psABI's dictates with respect to unnamed bit-fields.  I've
also verified that the EDG front end when configured in the mode that
corresponds to PCC_BITFIELD_TYPE_MATTERS does not align structures
based on unnamed bit-fields.

In addition, stor-layout.c looks like it was trying o avoid changing
the structure alignment for unnamed bit-fields:

   if (PCC_BITFIELD_TYPE_MATTERS && ...) 
     {
       /* A named bit field of declared type `int'
	  forces the entire structure to have `int' alignment.  */
       if (DECL_NAME (field) != 0)
	 {
	    ...
	 }
      }

However, other code snuck in there and aligned the structure anyway.

I believe this change will affect few real programs.  It will only
matter if the unnamed bit-field is the most-aligned type of any of the
fields.  Even then, reducing the alignment will not affect individual
loads/stores from the fields -- they will still be appropriately
aligned.

So, after a test cycle, I plan to commit this change, claiming that
this is a bug fix.  If anyone disagrees, please do not hesitate to
object.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index: stor-layout.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/stor-layout.c,v
retrieving revision 1.137
diff -c -p -r1.137 stor-layout.c
*** stor-layout.c	23 Dec 2002 02:10:18 -0000	1.137
--- stor-layout.c	23 Dec 2002 03:50:31 -0000
*************** update_alignment_for_field (rli, field, 
*** 715,734 ****
        && DECL_BIT_FIELD_TYPE (field)
        && ! integer_zerop (TYPE_SIZE (type)))
      {
!       /* For these machines, a zero-length field does not
! 	 affect the alignment of the structure as a whole.
! 	 It does, however, affect the alignment of the next field
! 	 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);
  	  desired_align = ADJUST_FIELD_ALIGN (field, desired_align);
  	}
  
!       /* A named bit field of declared type `int'
! 	 forces the entire structure to have `int' alignment.  */
        if (DECL_NAME (field) != 0)
  	{
  	  unsigned int type_align = TYPE_ALIGN (type);
--- 715,730 ----
        && DECL_BIT_FIELD_TYPE (field)
        && ! integer_zerop (TYPE_SIZE (type)))
      {
!       /* A zero-length bit-field affects the alignment of the next
! 	 field.  */
!       if (integer_zerop (DECL_SIZE (field)) && ! DECL_PACKED (field))
  	{
  	  desired_align = TYPE_ALIGN (type);
  	  desired_align = ADJUST_FIELD_ALIGN (field, desired_align);
  	}
  
!       /* Named bit-fields cause the entire structure to have the
! 	 alignment implied by their type.  */
        if (DECL_NAME (field) != 0)
  	{
  	  unsigned int type_align = TYPE_ALIGN (type);
Index: doc/tm.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.184
diff -c -p -r1.184 tm.texi
*** doc/tm.texi	17 Dec 2002 16:47:45 -0000	1.184
--- doc/tm.texi	23 Dec 2002 03:50:34 -0000
*************** go slower in that case, define this macr
*** 1181,1197 ****
  Define this if you wish to imitate the way many other C compilers handle
  alignment of bit-fields and the structures that contain them.
  
! The behavior is that the type written for a bit-field (@code{int},
! @code{short}, or other integer type) imposes an alignment for the
! entire structure, as if the structure really did contain an ordinary
! field of that type.  In addition, the bit-field is placed within the
! structure so that it would fit within such a field, not crossing a
! boundary for it.
  
! Thus, on most machines, a bit-field whose type is written as @code{int}
! would not cross a four-byte boundary, and would force four-byte
! alignment for the whole structure.  (The alignment used may not be four
! bytes; it is controlled by the other alignment parameters.)
  
  If the macro is defined, its definition should be a C expression;
  a nonzero value for the expression enables this behavior.
--- 1181,1199 ----
  Define this if you wish to imitate the way many other C compilers handle
  alignment of bit-fields and the structures that contain them.
  
! The behavior is that the type written for a named bit-field (@code{int},
! @code{short}, or other integer type) imposes an alignment for the entire
! structure, as if the structure really did contain an ordinary field of
! that type.  In addition, the bit-field is placed within the structure so
! that it would fit within such a field, not crossing a boundary for it.
  
! Thus, on most machines, a named bit-field whose type is written as
! @code{int} would not cross a four-byte boundary, and would force
! four-byte alignment for the whole structure.  (The alignment used may
! not be four bytes; it is controlled by the other alignment parameters.)
! 
! An unnamed bit-field will not affect the alignment of the containing
! structure.
  
  If the macro is defined, its definition should be a C expression;
  a nonzero value for the expression enables this behavior.