[jdoerfert]

Generally, yes. Though, as always, these things are hard to summarize in one sentence and depend on the standard version (pre/post C++11). This post might shed some light on the options we are considering for Clang right now: https://reviews.llvm.org/D94367#2489090

[souprock]

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor.

The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

[gpderetta]

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

[volta87]

> The infinite loop being UB was added because it prevents some important code motion optimizations

Which ones?

If this optimizations are so important, how come Rust was designed in such a way to make them impossible? Also, how does this fit, e.g., the benchmark game results which show that Rust is faster than C for all benchmarks considered there ?

[gpderetta]

Store sinking for example, which is unsafe unless the loop is guaranteed to terminate.

C does not have this guarantee (at least not in all cases). Also rust is compiled with the llvm backend, so my understanding is that in practice rust assumes that loops terminate. See:

https://github.com/rust-lang/rust/issues/28728

There are llvm directives that can be added to prevent the optimization, but they are rejected by the rust maintainers exactly because they would cause performance regressions.

[souprock]

Uh, so what?

Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

Actually, this is worse. Letting the loop be UB is like letting a true "if" be UB. Just never mind the code actually written; surely it doesn't mean what it says.

[gpderetta]

> Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

that's actually the case already. A missing default is UB if the switch condition does not match any of the cases. And C compilers already optimize accordingly.