“Pack it in, mathematicians, someone owes LLVM a million bucks”

I didn't edit any comments, though I can appreciate that a quick skim might leave you with a different impression, and returning might lead you to believe I must have edited it. But I didn't.

I really do think we've just been talking past each other. When something is as obviously "tongue-in-cheek" as the original post, I find it funny when people (a) get the joke, then (b) play it with a completely straight bat. It appears that doesn't cross cultural boundaries in the way I thought it would.

You're not alone ... some of my comments are getting significant numbers of downvotes.

<shrug> ... "Humour".

I'll go back to appearing humourless and commenting purely technically on purely technical things. Meanwhile ... nice to connect with you ... thanks for the responses.

This happens because (paraphrased) the standard dictates that loops without side-effects eventually terminate, and all other programs have undefined behaviour. You can't turn hitting that undefined behaviour into a compiler error, as distinguishing between the two requires solving the halting problem. You can remove the whole assumption, but that limits the optimization capabilities of the compiler. That gives a trade-off: do we want actual infinite loops, or do we want better optimizations? The second seems more useful to me, even though it might sometimes give surprising behaviour for the programmer.

I believe it to be the case that any optimization in conjunction with a non-conforming program can lead to a subtle or hard-to-understand bug, including giving literally the wrong answer. So what is the solution? Disallow optimization, or go to hellish lengths to write a hard-to-follow spec that only permits optimizations that do not surprise people?

On the other hand, it is not hard for me to incorporate into my mental model of a language that a program should eventually "do something" and if it doesn't, it is literally a wrong program.

In fact, that's exactly what I thought when I saw the code in question. Before even realizing what it is about: I read it like a normal program, I saw that it can only ever return true, therefore that code can do only one thing, and all that fluff in there does not impact the end result. So I don't think it's particularly non-obvious, but it does require something from the reader. I'm ok with that, there's a lot in C and C++ you can't just assume.

I call this a "weird program." It's trying to brute-force an answer out of the computer, but it's the kind of an answer that may or may not ever come. Hardly unlike a program that tries to answer the halting problem. Not necessarily an illegitimate program (bruteforcing is a legitimate way to find answers), but not the kind of thing you'd put inside a normal application. So I'm not concerned about normal applications running into this issue much. If a normal application could go into an infinite do-nothing loop, that is almost definitely a bug -- a literally wrong program. The optimization here only changes how that wrongness manifests, which is expected for UB & optimizations.

I do like that C gives you the escape hatch of using a constant controlling expression if you really want a true "potentially-infinite" loop.