This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC extension for atomic access to members


On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote:
> I would like to see the GCC project to document that if the address of a 
> member is taken, this does not constitute an access to the object as a 
> whole.
> 
> That is, in the following code:
> 
> #include <stdatomic.h>
> 
> struct S {
>    _Atomic int a;
>    int b;
> };
> 
> int
> load_a (struct S *p)
> {
>    return atomic_load_explicit (&p->a, memory_order_relaxed);
> }
> 
> int
> store_b (struct S *p, int b)
> {
>    p->b = b;
> }
> 
> If one thread calls load_a and another thread calls store_b on the same 
> struct S *, no data race happens.

There is no data race in this example; a and b are separate objects as
far as the memory model is concerned.  That's my understanding and I
believe also the understanding in the C++ committee.

> This is an extension over the C standard because of the way “->” is 
> defined.  C requires that E1->E2 it is evaluated as (*(E1))->E2, and *E1 
> is defined as an access to the entire struct, so there is a data race in 
> load_a with the assignment in store_b.

If ISO C really says that this is potentially a data race, then that's a
bug in the standard I'd say.  I see no need to have an extension for
this (module there potentially being a real bug in the standard).



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]