Reference (section label): [intro.memory]

Issue description

int x, y;
struct awoo_t {
    int *p, &r;
} awoo{&x, x};

void thread_w() {
    new (&awoo) awoo{&y, y}; // transparent replacement
}

void thread_p() {
    auto p = awoo.p; // data race
}

void thread_r() {
    auto& r = awoo.r; // OK ?! refer to x or y?
}

Assuming that thread_w(), thread_p(), and thread_r() are executed concurrently, thread_r has well-defined behavior despite binding a reference to a glvalue which changes the identity that it determines concurrently.

Paradoxically (and unlike thread_p(), in which a data race occurs), this is well-defined because a memory location is

• currently, "an object of scalar type", or
• after the current resolution of CWG1953, "the storage occupied by the object representation of an object of scalar type".

Therefore, storage occupied by references (which is possible; see [dcl.ref] p4) is immune from data races, but it should not be.

Suggested resolution

This resolution is relative to CWG1953, 2024-10-25.

Update [intro.memory], paragraph 3 as follows:

A memory location is the storage occupied by the object representation of either

• an object of scalar type that is not a bit-field, or
• a maximal sequence of adjacent bit-fields all having nonzero width., or
• an object in which a reference is nested.