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