You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the following example is rejected by some implementation, because they think volatile reading is performed (Godbolt link).
int n{};
structS { int& r; };
constexpr S s{n};
constexprvolatile S s2{n};
static_assert(&static_cast<constvolatile S&>(s).r == &n); // GCC rejects thisstatic_assert(&s2.r == &n); // GCC and Clang reject this
However, the standard wording doesn't ever seem to consider s or s2 to be accessed. It's unclear whether this is intended.
Also, assuming f1 and f2 are concurrently executed in different threads in the following example.
structS { int& r; }; // Note that S is trivially copyable and thus memcpy/memmove calls can be well-defined.
S s{/* ... */};
voidf1() {
int* p = &s.r;
// operations unrelated to s
}
voidf2(const S& s2) {
std::memcpy(&s, &s2, sizeof(S));
}
It seems that there can't be data race (in the standard meaning) due to the current specification because s is not considered accessed in f1. But presumably there should be UB due to data race.
A note in [intro.memory] suggests that this falls into the "additional memory location" case. However, the current specification doesn't seem to allow such additional memory location to be observable or accessed.
Suggested resolution:
The text was updated successfully, but these errors were encountered:
We don't allow reading the value of even a constexpr volatile int in a constant expression, so presumably it is intended that &s2.r == &n (for example) is not a constant expression.
jensmaurer
changed the title
[expr.ref] Evaluating a non-static reference member is not access
CWG2957 [expr.ref] Evaluating a non-static reference member is not access
Nov 11, 2024
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [expr.ref], [intro.memory]
Link to reflector thread (if any):
Issue description:
Currently, the following example is rejected by some implementation, because they think volatile reading is performed (Godbolt link).
However, the standard wording doesn't ever seem to consider
s
ors2
to be accessed. It's unclear whether this is intended.Also, assuming
f1
andf2
are concurrently executed in different threads in the following example.It seems that there can't be data race (in the standard meaning) due to the current specification because
s
is not considered accessed inf1
. But presumably there should be UB due to data race.A note in [intro.memory] suggests that this falls into the "additional memory location" case. However, the current specification doesn't seem to allow such additional memory location to be observable or accessed.
Suggested resolution:
The text was updated successfully, but these errors were encountered: