[llvm-bugs] [Bug 43686] clang handles differently signed overflow depending on variable constness and its storage

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43686

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Richard Smith <richard-llvm at metafoo.co.uk> ---
OK, here's what's happening:

When we see the declaration of 'var', we evaluate its initializer to
a) produce warnings if it's constant-evaluatable but evaluating it results in
overflow
b) see if we can constant-fold it to a known constant value in the frontend

Both of those are only possible if i32_max is declared 'const'. So that's why
you get a warning and can observe the value of 'res' wrapping around in that
case (after producing the overflow warning in the frontend we happen to give
the two's complement value). This is not easy to change, because the evaluation
step is performed locally without any control flow knowledge (we have no way to
know whether i32_max was modified after its initialization when locally
checking the initializer of 'var').


If i32_max is not declared 'const', then the optimizer reasons that i32_max + 3
< i32_max is false (before inlining numeric_limits<...>::max), which is why you
happen to get "is 0" for those cases.

In the 'static' case, I think what's happening is that LLVM isn't sure that
'printf' doesn't modify the value of i32_max, so it reloads it when computing
the return statement, and thus it isn't able to prove that the return value is
0. As a result, you happen to get the value 1 returned.


Note that none of the above is guaranteed in any way, and it's all subject to
change, because this is undefined behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191028/f18c8dd4/attachment.html>