Oddity in place_field

[Mark Mitchell]

There's some oddness in the way that BIGGEST_FIELD_ALIGNMENT and
maximum_field_alignment are handled in stor-layout.c.  Consider
something like:

 struct S { 
   char c;
   long long l : 64;
 };

On the x86, we have BIGGEST_FIELD_ALIGNMENT set to 32 (i.e., the
alignment of a double.)  So, we align the bit-field on a
double-aligned boundary.

  #ifdef BIGGEST_FIELD_ALIGNMENT
    /* Some targets (i.e. i386, VMS) limit struct field alignment
       to a lower boundary than alignment of variables unless
       it was overridden by attribute aligned.  */
    if (! user_align)
      desired_align =
	MIN (desired_align, (unsigned) BIGGEST_FIELD_ALIGNMENT);
  #endif

But then we go ahead and align the entire structure as if for a `long
long', because maximum_field_alignment is zero:

      /* 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);

	  if (maximum_field_alignment != 0)
	    type_align = MIN (type_align, maximum_field_alignment);
	  else if (DECL_PACKED (field))
	    type_align = MIN (type_align, BITS_PER_UNIT);

	  rli->record_align = MAX (rli->record_align, type_align);
	  if (warn_packed)
	    rli->unpacked_align = MAX (rli->unpacked_align, 
				       TYPE_ALIGN (type));
	}

The upshot is that even though the `long long' bit-field is
misaligned, the structure itself is padded out as if it were correctly
aligned.  That seems wasteful to me.

I'm not sure we can change this -- there are ABI impliciations,
obviously -- but I'm trying to understand if there's a rationale here.

Thanks,

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