[PATCH] D65239: [analyzer] RangeConstraintManager: Apply constraint ranges of bitwise operations

[Csaba Dabis via Phabricator via cfe-commits]

Charusso marked 3 inline comments as done.
Charusso added a comment.

In D65239#1599889 <https://reviews.llvm.org/D65239#1599889>, @NoQ wrote:

> Aha, great, the overall structure of the code is correct!


Thanks! Now it is more formal. The only problem it does not change anything on LLVM reports, where we are working with the `test_non_null_lhs_range_to_null_result_feasible` test case.



================
Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:477
+
+  // For all of the bitwise operations,
+  // if they remain in that 'SymIntExpr' form that means we cannot evaluate the
----------------
NoQ wrote:
> Let's do some math.
> 
> Suppose `$x` is in range `[2, 3]`. In this case the true range for `$x & 1` is `[0, 1]` (because `2 & 1 == 0` and `3 & 1 == 1`).
> 
> The range for `$x & 8` would be `[0, 0]`.
> 
> The range for `$x | 8` would be `[10, 11]`.
> 
> The range for `$x << 1` would be `[4, 4], [6, 6]`.
> 
> The range for `$x >> 1` would be `[0, 1]`.
> 
> None of these ranges are contained within `[2, 3]`. In fact, none of them even contain either `2` or `3`. However, when you intersect the resulting range with `[2, 3]`, you make sure that the resulting range is contained within `[2, 3]`. I don't think that's correct.
I have added a test case to see how bad our evaluation at the moment. That is why I saw that we are just narrowing ranges and the contradiction only could happen at concrete zero range based.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65239/new/

https://reviews.llvm.org/D65239