This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC extension for atomic access to members
- From: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Sep 2017 22:07:54 +0200
- Subject: Re: GCC extension for atomic access to members
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=triegel at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 61147C0546D5
- References: <bbe0877c-7651-a732-cfe1-6d6b326d6d7c@redhat.com>
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).