> 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 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. > 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 something. -- Eric Botcazou