[PATCH][4.8] C++ memory model bitfield handling rewrite

[Jonathan Wakely]

On 7 February 2012 14:00, Richard Guenther wrote:
> On Tue, 7 Feb 2012, Jonathan Wakely wrote:
>
>> Hi Richard,
>>
>> re http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00280.html (I'm not
>> subscribed to gcc-patches so only read it in the archive)
>>
>> > Note that in the above case
>> > tail-padding is _not_ reused (for some reason).
>>
>> Tail-padding in PODs can't be reused according to the ABI.  Give Base
>> a user-defined constructor or destructor and it gets reused.
>
> Ah, thanks.  Thus, for the following testcase
>
> struct Base {
>    Base();
>    int i : 1;
> };
> struct Deriv : Base {
>    char d : 2;
>    char x;
> };
>
> Deriv s;
> void foo ()
> {
>  s.i = 1;
>  s.d = 2;
>  s.x = 3;
> }
>
> What does the C++ memory model say about accesses to s.i, s.d and s.x?

It depends whether s.i and d.i are "adjacent bit-fields" or not.

"A memory location is either an object of scalar type or a maximal
sequence of adjacent bit-fields all having non-zero width."

I think they are not adjacent, so [intro.memory] 1.7 in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
(that clause is identical in n3337 and C++11 standard)  says s.i and
s.d are separate memory locations, so can be updated concurrently in
separate threads without races.

"Two threads of execution (1.10) can update and access separate memory locations
without interfering with each other."

> What would it have said for -fabi-version=1 where for
> we place s.i and s.d into the same byte?

I think it says they shouldn't be in the same byte :-)

The memory model talks about separate memory locations. If the
compiler puts separate memory locations into the same byte then it
still has to allow concurrent updates to not interfere.

But I'm not an expert on the memory model so check those claims with
someone else.