alt Hacker NewsIn LLVM, the result of floating-to-int conversion that is out of range of the int is a poison value, which means you get essentially the full unpredictability of UB.
That said, I'm a little hard-pressed to think of optimizations that would actually take advantage of poison, because floating-point range isn't really computed in the optimizer.
Here's (my modified version of) an example someone came up with on lobste.rs: https://godbolt.org/z/e69b4Tqbs
I don't know exactly which optimization passes do what, but a few observations:
* The 'foo(unsigned int n)' function should never return a value that's greater than 'n', since it returns 'i < n ? i : n'.
* The value printed by the 'foo' function should always be the same as the value that's returned.
Yet the value it prints is 2700624104 (which is greater than 'n', which is 10 in this case), and the returned value is 2700623376, which is different. (The exact numbers vary run to run)
If the conversion "just" resulted in a bogus value, we would have expected some number <=10 to be printed two times.