Yeah, my problem isn't that optimization is changing the code per-se, it's that it is introducing a non-obvious bug by doing so. Ostensibly that loop either returns true or never returns. What if it were provided a number that would never return (assume this is possible given the algorithm provided), but because of the "optimization" now returns true? It literally gives us the wrong answer.
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.
Consider this hypothetical: the loop is only potentially infinite because it is written incorrectly. In testing, I would notice an infinite loop and debugging where that is happening is pretty trivial. When the compiler optimizes that away to just always return true, it has made the source of the bug much more difficult to pin down because the code I asked the compiler to make produces a completely different result than what the compiler compiled.
Some bugs end up being extremely difficult to debug. I accept that as a fact of life; in exchange, we get pretty decent performance.
Guess what I do when there's a bug I have a hard time pinning down? Recompile with optimizations turned off.
By the way, I don't think I have ever witnessed a bug caused by an accidentally-infinite loop getting optimized out. So making that almost-never-happens situation easier to fix is not worth trading any optimizations for, imo. I'd rather just get a warning from compiler/static analyzer (if the code isn't the way it is due to macro expansion).
I think it's easier to define in a standard what's conforming behavior than it is to exactly and precisely define all the possible optimizations a compiler may (or may not) perform. So "undefined behavior" is a decent starting point. Exceptions can be added later, but if you try to spec all allowed optimizations in advance, the spec is going to be massive and also a massive burden.