Andrew's mail to gcc-patches keeps bouncing. Trying on his behalf.
-------- Original Message --------
Subject: Re: [C++0x] contiguous bitfields race implementation
Date: Tue, 09 Aug 2011 09:49:51 -0400
From: Andrew MacLeod <amacl...@redhat.com>
To: Richard Guenther <richard.guent...@gmail.com>
CC: Aldy Hernandez <al...@redhat.com>, Jason Merrill
<ja...@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>, Jakub Jelinek
<ja...@redhat.com>
On 08/09/2011 06:13 AM, Richard Guenther wrote:
struct A
{
int i;
bool a:1;
}
struct B : public A
{
bool b:1;
}
The tail-padding of A is 3 bytes that may be used by b. Now, is
accessing a allowed to race with accessing b? Then the group for
a may include the 3 bytes tail padding. If not, then it may not
(in which case using DECL_SIZE would be appropriate).
I do not believe 'b' can share a memory location with 'a', and therefore
a data race between them would not be allowed. This would appear to be
analagous to nested structures, and that is spelled out as being
separate memory location. I'm sure that's the intent anyway.
A bit-field and an adjacent non-bit-field member are in separate
memory locations. The same
applies to two bit-fields, if one is declared inside a nested
structure declaration and the other is not, or if the
two are separated by a zero-length bit-field declaration, or if they
are separated by a non-bit-field member
declaration
Now seeing all this - and considering that this is purely C++ frontend
semantics. Why can't the C++ frontend itself constrain accesses
It is C++ right now, but they seem to be trying to get C1x to align with
C++1x on a lot of this threading/atomic/data race stuff. C1x Draft 1539,
section 5.1.2.4 has a lot of similar text about data races, but not a
lot of specifics about things like bitfields (yet anyway)... It wouldn't
surprise me if this has to be dealt with eventually in C as well since
its all about predictability in a multi-threaded environments, but who
knows. Maybe someone more familiar with the committee's intentions can
clarify that aspect.
Andrew
