This is the mail archive of the 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 09/18/2017 10:07 PM, Torvald Riegel wrote:
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

That is, in the following code:

#include <stdatomic.h>

struct S {
    _Atomic int a;
    int b;

load_a (struct S *p)
    return atomic_load_explicit (&p->a, memory_order_relaxed);

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.

I'm not sure what the C++ standard says in this matter.

C++ may indeed have addressed this and related issues (e.g., that a memory location which is passed by reference to a function is not actually read in the caller).

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).

GCC relies on the implicit access to the full struct object in this case:

struct T {
  int a;
  int b;

opt (struct T *p1, struct T *p2)
  p1->a = 1;
  p2->b = 2;
  return p1->a;

It optimizes the load of p1->a to 1. This is not a valid transformation if there is no access to the entire struct object because it's the only thing in this code which asserts the dynamic type of the memory allocation is that of T, so that the members a and b do not alias.

This is why I think this issue is difficult to fix.


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