ASDenysPetrov added a comment.
@martong wrote:
I think you did get it. I'm not talking about range but about concrete int. And
I see that the current behavior needs an improvement or rework.
Consider next code, which I used in my example:
1. void test(int x) {
2. assert((short)x == 0);
3. clang_analyzer_eval(x == 1);
4. }
Your patch does next:
- on the line 3 we know that `(int)(short)(int x) = 0` and `(int x) = 1`
- simplify `(int)(short)(int x)`. Try to get a constant for `(short)(int x)`.
Result is nothing because it is not presented in the range map. **Continue
**unwrapping.
- go deeper and simplify `(short)(int x)`. Try to get a constant for `(int
x)`. Result is 1. **Stop **visiting.
- return 1.
- intersect the range of the original symbol `(int)(short)(int x)` which is
**0** and the range which is returned - **1**
- result is an **infeasible** state.
My patch above yours does next:
- on the line 3 we know that `(int)(short)(int x) = 0` and `(int x) = 1`, but
now we also know that `(short)(int x) = 0` as an equivalent for
`(int)(short)(int x)` due to the improvement.
- simplify `(int)(short)(int x)`. Try to get a constant for `(short)(int x)`.
Result is 0. **Stop **visiting.
- return 0.
- intersect the range of the original symbol `(int)(short)(int x)` which is
**0** and the range which is returned - **0**
- result is a **feasible** state.
Here what I'm saying. This is not about ranges. This simplification dosn't take
into account that differents operands of the cast symbol may have different
asocciated ranges or constants. And what do we have to do we them in this case?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126481/new/
https://reviews.llvm.org/D126481
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
