On Thu, Mar 22, 2012 at 12:47 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> But the bitfield group _does_ start on a byte boundary.  At least
>> that's what the new code in stor-layout ensures.
> No, it doesn't, since it does the computation on a record by record basis.
> Here we have a bitfield group that starts in a record and ends up in a nested
> record.
>> It's ok to assume the group starts on a byte boundary.  But it's not
>> ok to modify bits outside of the access, so the RMW cycle has to mask
>> them properly.
> We have 2 options:
>  1. the GCC 4.7 approach where get_bit_range returns 0 for bitstart, which
> doesn't make much sense but is in keeping with store_bit_field.
>  2. the GCC 4.8 approach where get_bit_range attempts to return a more correct
> value, but is currently wrong (bitregion_start=11, bitregion_end=18) because
> the representative of the bitfield is wrong.  The real representative of the
> bitfield is outside the record type.

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

At least I still can't see where things go wrong from inspecting the
code ...


> --
> Eric Botcazou

Reply via email to