“Pack it in, mathematicians, someone owes LLVM a million bucks”
twitter.com
twitter.com
Secondly, as others have already explained, endless loops are UB and optimized away, but, thirdly, even if they weren't, C++ integers are more like Z/nZ than Z and checking if Collatz holds in Z/nZ is rather trivial.
This is an widely-held misconception, but C++ signed integers are _nothing_ like Z/nZ. Unsigned integers are (except for division), and machine arithmetic often is, but in the C++ abstract machine, signed overflow is undefined behavior.
That soundbite also repeats/paraphrases what thread author Joe Groff said "LLVM considers infinite recursion to be UB,"
But... the key is infinite loops without side effects can be optimized away. Endless loops even without a provable termination (The Halting Problem) are not UB.
But in this case, the value 'x' has a side effect of determining what bool of true/false value to return. That while() loop does not look like it's free of side effects.
That leaves only the loop itself, which can run infinitely long (which would be UB, and the compiler is free to assume that won't happen), or it won't, in which case it will always return true. Thus, like them or not, the rules of C++ allow this particular outcome.
I can't say I like this kind of optimisation. Sure, you can construct neat circus tricks with it like this, but other than that it seems pretty pointless for real-world software, and something that could easily turn a simple mistake into a debugging disaster.
(b) The Collatz Conjecture isn't one of the Millennium problems;
(c) It's using bounded numbers in the range where the Collatz Conjecture is known to be true;
(d) It seems reasonable to say "If this routine exits then the value will be "true";
(e) None of what I say here is deep or new, so when people get excited about this sort of thing it makes me wonder what I've missed.
So ... what have I missed?
So the compiler doesn't actually need to figure out if the loop is infinite or not.
Technically, it doesn't, but it requires programs to make forward progress, which is defined as either terminating, calling I/O functions, accessing a volatile variable or performing an atomic or synchronization operation. Infinite loops that'll eventually do one of these are perfectly valid C++ and don't have to terminate.
But also a layer deeper, collatz() takes a uint128 as input and the Collatz conjecture has already been proven to be true for all numbers that would fit into a uint128. So LLVM arrives to the correct answer (`return true`) because of the wrong reason, mathematically speaking.
Specifically, Collatz says "if x is even then x /= 2" but the code checks "x is odd".
(b) the Millennium problems are not the only million-dollar prizes in mathematics
(c) part of the joke
(d) part of the joke (and part of the C++ standard)
Searching 'collatz conjecture prize' quite literally puts a prize of a bout 120MM Yen (~ $1MM) as the top result.
Thanks.
<shrug>
Thanks for finding this and letting me know, I've learned something.
It's not but there are more bounties out there than just the Millenium list. For the Collatz Conjecture specifically there's a 120M Japanese Yen prize which at this moment is a bit more than 1 million USD.
https://www.prnewswire.com/news-releases/bakuage-offers-priz...
Thanks.
For instance not all languages that target LLVM will get this result. That is interesting.
The input is an unsigned __int128, and I believe Collatz has only been verified up to 2^68.
I get that it is supposed to be a joke, but it kind of falls flat because it misses the point entirely.
I'd also note that this particular footgun only exists in C++, the C standard allows loops that never terminate and never do IO or volatile memory access.
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.
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 the real problem here is that people underestimate the complexity of C and C++. It often feels like it would be easy to guess what the assembly would look like for some snippet of C/C++ code (especially when it's not using any C++ features, such as the loop in the article) when we really should be thinking in terms of the abstract machine that the standard defines.
I just don't think having 'gotcha' rules the compiler exploits to do whatever it wants regardless of programmer intent is a good idea, and that's how C/C++ treats UB. UB should be a compiler error and force the programmer to specify what they want the result to actually be so there are no assumptions on the programmer end and no surprises from the compiler.
That's a fair point, but it still feels wrong to me that the compiler can throw away large chunks of code and change the outcome of the function silently.
> UB should be a compiler error and force the programmer to specify what they want the result to actually be so there are no assumptions on the programmer end and no surprises from the compiler.
Many types of UB are not easily detected at compile time, or cannot be detected in advance at all. For instance, prompting the user for an integer and incrementing it by 1 is UB when the user enters the maximum value of an integer. So should the compiler forbid adding two numbers unless you explicitly guard against overflow? Perhaps it should, but the resulting language definitely wouldn't look anything like C.
Besides, it's not that the compiler is going out of its way to screw you over with a 'gotcha' rule, it's just optimizing using the assumption that your program is free of UB. As a programmer it is your responsibility that there is no UB. If you feel there are too many pitfalls you could use a different programming language, lobby the standards organization for a standard that has less UB, or use compiler options to detect it (e.g. ubsan for clang).
What should your program do if you overflow a 32 bit signed integer? What if you overflow a 64 bit signed integer? Should it do the "expected" thing and wrap according to two's complement? How do you intend to do that efficiently in a portable manner?
This rabbit hole can be chased forever until you are left with every C++ implementation being a full blown interpreter.
This is especially true given that (a) there is no standard compliant way of checking if you had overflow, and (b) the most pedantically correct way of looping over arrays and such uses an unsigned type (size_t), negating the usual claims about optimization opportunities.
Thus the word "efficiently" in my comment. By requiring weird and almost certainly buggy behavior to be defined, you require the program to behave more like an interpreted program, with associated performance costs.
Doesn't seem like UB but optimizing effectless loops out is permitted.
In a valid C++ program, every thread eventually does one of the following:
* terminate
* makes a call to an I/O library function
* performs an access through a volatile glvalue
* performs an atomic operation or a synchronization operation
It's fairly obvious how a loop that has none of these side-effects is thus a target to get turned into one that's guaranteed to terminate.
Maybe they secretly hope that some tool, someday, will spit out a correct proof? :)
[1] https://github.com/sosy-lab/sv-benchmarks/blob/svcomp17/c/te...
Not sure why he used the word "recursion" since collatz() is not calling itself.
In reality, the reason is that out of the two outcomes: true or infinite loop, the infinite loop violates the standard, and therefore, the result must be true. Another way to see it is that the only way for the code to be valid is if the programmer knows that the Collatz conjecture is true, and the compiler trusts the programmer, saying that the compiler knows the answer to the Collatz conjecture is a kind of circular reasoning.
There are other issues here: the numbers are bounded (a 128 bits integer), but the conjecture is not. And no million dollar prize have been assigned to this problem (it is not one of the millenium problems). Also, an infinite loop is not a result, it is actually the textbook example of an undecidable problem.
> 6.9.2.2 Forward progress [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.
That loop doesn't ever do any of the second through fourth things, and if it didn't return true, then it would never terminate either, so Clang is allowed to assume that it will eventually return true. And since the loop doesn't have any other effects visible outside the function, it can be optimized away entirely.
unsigned __int128