> 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
> 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 
integral mode.

> 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 

Eric Botcazou

Reply via email to