On Thu, 22 Mar 2012, Richard Guenther wrote: > On Thu, 22 Mar 2012, Eric Botcazou wrote: > > > > bitregion_start == 11 looks bogus. The representative is starting at > > > > > > DECL_FIELD_BIT_OFFSET (repr) > > > = size_binop (BIT_AND_EXPR, > > > DECL_FIELD_BIT_OFFSET (field), > > > bitsize_int (~(BITS_PER_UNIT - 1))); > > > > > > which looks ok > > > > It cannot be OK if you want it to be on a byte boundary, since the field > > isn't > > on a byte boundary itself and they have the same DECL_FIELD_BIT_OFFSET (0). > > 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?! But how can DECL_OFFSET_ALIGN > be still valid for such field? 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? > > 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.
Btw, now checking with gdb, DECL_OFFSET_ALIGN is always 128 for all of the fields - that looks bogus. DECL_ALIGN is 1, but that doesn't mean DECL_OFFSET_ALIGN should not be 1 as well, no? Thanks, Richard.
