[Bug c/71849] New: bitfield placement of overly aligned type

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71849

            Bug ID: 71849
           Summary: bitfield placement of overly aligned type
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38881
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38881&action=edit
testcase

Iain Sandoe & I have discovered an anomaly with the placement of bitfields with
a paradoxically aligned underlying type (alignment > size).  The calculation in
 excess_unit_span (stor-layout.c) erroneously considers such bitfields to
always straddle an allocation unit boundary, unless they start at bit-offset 0
within such an allocation.

The testcase contains two struct definitions that differ only by the underlying
type of the SECOND field.  In char_bit, it's type is 'char
__attribute__((aligned(__alignof(int))))' -- a char with int alignment.  In
int_bit, its type is plain int.  Both are 1 bit in size.

One might expect these two structs to be laid out the same.  That doesn't
happen.

char_bit's second field is placed at byte offset 4 bit 0, whereas int_bit's
second field is placed at byte offset 0 bit 1.  The struct sizes and offsets of
the third field are also different, as fallout from this change.

It seems excess_unit_span (or its callers) should check for such paradoxical
bitfield types.

However, (a) this is probably a rare case and (b) changing this is going to
break ABI compatibility.  So we may not care (but I couldn't find an existing
bug capturing this problem).

FWIW clang lays out these structs identically, which is how we became aware of
the problem.