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. > > the size of the representative is (at minimum) > > > > size = size_diffop (DECL_FIELD_OFFSET (field), > > DECL_FIELD_OFFSET (repr)); > > gcc_assert (host_integerp (size, 1)); > > bitsize = (tree_low_cst (size, 1) * BITS_PER_UNIT > > + tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1) > > - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1) > > + tree_low_cst (DECL_SIZE (field), 1)); > > > > /* Round up bitsize to multiples of BITS_PER_UNIT. */ > > bitsize = (bitsize + BITS_PER_UNIT - 1) & ~(BITS_PER_UNIT - 1); > > > > that looks ok to me as well. Is the issue that we, in get_bit_range, > > compute bitregion_start relative to the byte-aligned offset of the > > representative? > > The issue is that the representative is assumed to be on a byte boundary in > get_bit_range, but it isn't in the case at hand. So either we cope with that > (this is the GCC 4.7 approach) or we change the representative somehow. I think we can't change it to be on a byte-boundary, the same record may be used at different bit-positions, no? > IOW, either we pretend that a bitfield group is entirely contained within a > single record type or we acknowledge that a bitfield group can cross a record > boundary. 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. Richard.
