OikawaKirie added a comment. In D92634#2477342 <https://reviews.llvm.org/D92634#2477342>, @danielmarjamaki wrote:
>> However, the mainstream compilers like GCC and Clang implement this as the >> overflowed value, and some programmers also use this feature to do some >> tricky things. > > hmm.. you mean if some -fwrapv flag is used right. yes I should disable this > checking then. > > For information, I am not very worried about signed integer overflow. I am > mostly worried about the compiler optimisations. If the compiler determines > that there is signed integer overflow in a execution path and removes all > code in that path. > > I was inspired by this blog post: https://www.airs.com/blog/archives/120 > > This function: > > int f(int x) { return 0x7ffffff0 < x && x + 32 < 0x7fffffff; } > > might be optimized to: > > int f(int x) { return 0; } Yes, you are right. Currently, in the CSA, the symbolic execution engine will return true for this function. Condition `0x7ffffff0 < x` will assume x to be [2147483632, 2147483647], then `x + 32` will be evaluated to [-2147483632, -2147483617] which will make the check return true. But for the example you mentioned, I prefer implementing this check with a coding style checker for Clang-Tidy, although the integer overflow checker in the CSA is also necessary. As the evaluation result potentially conflicts with the literal arithmetical result, reporting directly this conflict condition expression would be easier for programmers to diagnostic the code. Besides, as far as I am thinking, the compiler optimizes the expression as it is literally inferable, i.e. the result should be determinable literally during compilation. Otherwise, it will be computed during runtime. Therefore I suggest you can do a similar check with the ASTMatcher, since the `and` and `or` conjunctions will be removed in the CFG. BTW, I cannot optimize function `f` to returning zero directly with GCC-10.2.1 and Clang-10.0.1 under -O3. Should I add any other flags? Or it is version specific? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92634/new/ https://reviews.llvm.org/D92634 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
