Full name of submitter (unless configured in github; will be published with the issue): Jim X

[intro.races] p17 says

Two actions are potentially concurrent if

• they are performed by different threads, or
• they are unsequenced, at least one is performed by a signal handler, and they are not both performed by the same signal handler invocation.

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below.
Any such data race results in undefined behavior.

However, [dcl.type.cv] p5 says

The semantics of an access through a volatile glvalue are implementation-defined.

Consider this example:

volatile int val = 0;
// thread 1:
val  = 1;
// thread 2:
val = 2;

Each thread modifies the object via the volatile glvalue. However, according [intro.races] p17, these two operations are not atomic and are unordered, so [intro.races] p17 says the program has UB. However, [dcl.type.cv] p5 says that the semantics are implementation-defined. So, what's the behavior of this program?

Which rule trumps the other?

Suggested Resolution: