On Thu, 22 Mar 2012, Eric Botcazou wrote:
> > Yes, I have noticed that from what you can see in the code. So the
> > issue is that get_bit_range tells us that it's ok to touch bits
> > outside of the field - but that's obviously required. We may not
> > change bits that are not covered by the FIELD_DECL which now
> > somehow happens? That sounds like a latent bug in the bitfield
> > expander to me - it should never _change_ bits outside of bitpos/bitsize
> > as returned by get_inner_reference.
>
> It's the new C++0x memory model stuff:
>
> void
> store_bit_field (rtx str_rtx, unsigned HOST_WIDE_INT bitsize,
> unsigned HOST_WIDE_INT bitnum,
> unsigned HOST_WIDE_INT bitregion_start,
> unsigned HOST_WIDE_INT bitregion_end,
> enum machine_mode fieldmode,
> rtx value)
> {
> /* Under the C++0x memory model, we must not touch bits outside the
> bit region. Adjust the address to start at the beginning of the
> bit region. */
> if (MEM_P (str_rtx)
> && bitregion_start > 0)
> {
> enum machine_mode bestmode;
> enum machine_mode op_mode;
> unsigned HOST_WIDE_INT offset;
>
> op_mode = mode_for_extraction (EP_insv, 3);
> if (op_mode == MAX_MACHINE_MODE)
> op_mode = VOIDmode;
>
> offset = bitregion_start / BITS_PER_UNIT;
> bitnum -= bitregion_start;
> bitregion_end -= bitregion_start;
> bitregion_start = 0;
>
> which assumes that a bitfield group starts on a byte boundary. So this is
> probably indeed latent in GCC 4.7 as well.
But the bitfield group _does_ start on a byte boundary. At least
that's what the new code in stor-layout ensures.
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.
Richard.
