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.
