Something odd with an infinite loop.. about llvm-mos

[cogwheel]

However, at first I didn't expect it would optimize away my for(;;) ; loop, but here it has done so.

FWIW: here's a discussion in the FAQ about this: https://llvm-mos.org/wiki/Frequently_asked_questions#Why_is_the_compiler_removing_my_infinite_loops.3F

[juj]

Thanks!

Do you know if there is a standards paragraph about the Undefined Behavior? A cited blog article here https://stefansf.de/post/non-termination-considered-harmful/ follows the same logical fallacy: they claim that it is undefined behavior to write code that does not make forward progress, but then cites paragraphs of the standard which bear no mention about this undefined behavior: instead they write

This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven. 

from https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf , but again, there is no mention about undefined behavior, just they define that optimizers are allowed to generate code to assume that all loops will terminate. Jumping from that to UDB does not seem like a logical conclusion.

(I am not saying that the scenario could not be UDB, but at least on the face of the paragraphs from standards as worded do not seem to mention UDB that I could find. It would be odd to first remark that "this is intended to allow compiler to remove empty loops" to define a behavior, but then in actuality make it be Undefined Behavior instead)

I'd be happy to raise this to upstream LLVM, although just wanted to make sure there is nothing llvm-mos specific here first.

[mysterymath]

The simple while(true) infinite loops are well-defined in C; they're only tricky in C++. The C++ standard section that covers this is 6.9.2.3, Forward Progress:
https://eel.is/c++draft/intro.progress

The implementation may assume that any thread will eventually do one of the following:
- terminate,
- make a call to a library I/O function,
- perform an access through a volatile glvalue, or
- perform a synchronization operation or an atomic operation.

It's not so much that "infinite loops are undefined behavior". It's that code locations that can be proven to cause an infinite loop if reached can be considered unreachable. That also means that any code that would inexorably lead to those locations are also unreachable, transitively. The compiler can generally do whatever the heck it wants with unreachable locations, since they're unreachable. This goes all the way to main; the program can be assumed to terminate before main is ever reached. The jsr to __bss_start is actually a jsr to main, it's just that the routine is completely empty, with not so much as a rts. Accordingly, the disassembler mistakes it for another symbol.

Closing; this is a well known behavior of standards-compliant C++ compilers.