> Huh? If they have DECL_FIELD_BIT_OFFSET of zero they are at a byte
> boundary, no? Wait - the RECORD_TYPE itself is at non-zero
> DECL_FIELD_BIT_OFFSET and thus a zero DECL_FIELD_BIT_OFFSET for its
> fields does not mean anything?!
DECL_FIELD_BIT_OFFSET is relative to the enclosing record type.
> But how can DECL_OFFSET_ALIGN be still valid for such field?
Likewise, it is relative to DECL_FIELD_OFFSET, which is relative to the
enclosing record type.
> Obviously if DECL_FIELD_OFFSET == 0, DECL_FIELD_BIT_OFFSET == 0 then the
> offset needs to be aligned to DECL_OFFSET_ALIGN. Which then means
> DECL_OFFSET_ALIGN is a bit-alignment?
It's just a relative alignment, not an absolute one.
> Anyway, since we are trying to compute a nice mode to use for
> the bitfield representative we can give up in the second that
> we do not know how to reach BITS_PER_UNIT alignment. Or we can
> simply only try to ensure MIN (BITS_PER_UNIT, DECL_OFFSET_ALIGN)
> alignment/size of the representative. Of course the bitfield
> expansion code has to deal with non-byte-aligned representatives
> then, and we'd always have to use BLKmode for them.
But BLKmode forces byte alignment. Anything not byte-aligned must use an
> I think we can't change it to be on a byte-boundary, the same record
> may be used at different bit-positions, no?
> Sure, we acknowledge it can cross a record boundary. I just was not
> aware we cannot statically compute the bit-offset to the previous byte
> for a record type.
We can if we look into the entire object, not just the enclosing record. The
problem is that, while get_inner_reference and friends do the former, the new
code in stor-layout.c only does the latter.
OK, I think we should enter some sort of a degraded mode for these non-byte
aligned records, as they cannot occur in C/C++. I'll try to come up with