On Tue, May 23, 2023 at 7:52 AM Hans Boehm <
boehm@acm.org> 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) {
}
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(?)
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, and as such this kind of undefined behavior is out of scope of N3128. The abstract interpretation and concrete interpretation are ill-posed with regard to [intro.progress]/1.
Was N3128 intended to apply to all kinds of undefined behavior, or only undefined behavior involving undefined operations?