On Thu, 22 Mar 2012, Eric Botcazou wrote:

> > bitregion_start == 11 looks bogus.  The representative is starting at
> >
> >     = 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
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 
> 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.


Reply via email to