On 23/05/2023 03.34, Andrew Tomazos via Liaison wrote:
> On Tue, May 23, 2023 at 7:52 AM Hans Boehm <boehm_at_[hidden] <mailto:boehm_at_[hidden]>> wrote:
>
> As has been pointed out in some similar discussion, it's a bit tricky to define precisely what it means to "occur before an operation that has UB". I suspect we mostly mean "strongly happens before", but that leaves questions about where UB occurs. If I have
>
> volatile int v;
> int j= 1, k = 5;
> for (unsigned i = 0; i != 317; i += 14) {
> ++j;
> }
> for (unsigned i = 0; i != 317; i += 14) {
> ++k;
> v = i;
> }
>
> and the compiler merges the two loops, as intended, does that violate the concrete interpretation? The variable v is (incorrectly) updated, (long) before the first loop fails to terminate, and thus has UB(?)

And also, can there be a data race on "k" assuming a concurrent
thread is also looking at "k"?

> Is it correct to say that a statement of the form "The implementation may assume X", implies that if X is false, the program has undefined behavior?
>
> If so, the condition X may not contain any reference to an undefined operation, such as [intro.progress]/1 does not:
>
> "The implementation may assume that any thread will eventually [snip]"
>
> Thus it is not rendered undefined behavior via [intro.abstract]/4,

[intro.abstract] p4 is the root of the "undefined behavior" specification in C++.
I agree the phrasing "operation" is not stellar with respect to stuff such as
non-terminating loops or data races (improvement suggestions welcome), but the
intent is that it applies to all kinds of undefined behavior that are mentioned
in the rest of the standard.

Jens