manas added inline comments.
================
Comment at: clang/test/Analysis/constant-folding.c:280-281
+ if (c < 0 && c != INT_MIN && d < 0) {
+ clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+ clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+ clang_analyzer_eval((c + d) <= -2); // expected-warning{{UNKNOWN}}
----------------
vsavchenko wrote:
> manas wrote:
> > When I pull these cases out to a separate function (say testAdditionRules2)
> > in constant-folding.c then algorithm is able to reason about the range
> > correctly, but inside testAdditionRules, it is unable to figure stuff out.
> > Does it have something to do with constraints being propagated which we
> > discussed below?
> >
> > @vsavchenko wrote:
> > > I have one note here. The fact that we don't have a testing framework
> > > and use this approach of inspecting the actual analysis has an
> > > interesting implication.
> > >
> > > ```
> > > if (a == 10) { // here we split path into 2 paths: one where a == 10, and
> > > one where a != 10;
> > > // one goes inside of if, one doesn't
> > > . . .
> > > }
> > > if (a >= 5) { // here we split into 3 paths: a == 10, a < 5, and a in [5,
> > > 9] and [11, INT_MAX] (aka a >= 5 and a != 10).
> > > // 1 path was infeasible: a == 10 and a < 5
> > > // Two of these paths go inside of the if, one doesn't
> > > . . .
> > > clang_analyzer_eval(a == 10); // it will produce two results: TRUE and
> > > FALSE
> > > }
> > > clang_analyzer_eval(a == 10); // it will produce three results: TRUE,
> > > FALSE, and FALSE
> > > ```
> > >
> > > We don't want to test how path splitting works in these particular tests
> > > (they are about solver and constant folding after all), that's why we try
> > > to have only one path going through each `clang_analyzer_eval(...)`
> > >
> >
> >
> It might be that or it might be something different. Just by looking at this
> example, the previous `if` statement shouldn't add more paths that go inside
> of this `if`, so it shouldn't be the root cause.
> Whenever you encounter problems and you want to tell other people, **please,
> provide more detail**. Did you notice it when running the test case? What
> was the output? What did you try? How did you extract it into a separate
> function?
I put a new test function in `constant-folding.c` as:
```
void testAdditionRulesNew(int c, int d) {
if (c < 0 && c != INT_MIN && d < 0) {
clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
}
}
```
I tested this specific function as:
./build/bin/clang -cc1 -analyze -analyzer-checker=core,debug.ExprInspection
-analyze-function=testAdditionRulesNew constant-folding.c
And I got the following output:
../clang/test/Analysis/constant-folding.c:338:5: warning: FALSE
[debug.ExprInspection]
clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
which is correct.
But when I ran the same test inside `testAdditionRules`, using:
./build/bin/clang -cc1 -analyze -analyzer-checker=core,debug.ExprInspection
-analyze-function=testAdditionRules constant-folding.c
then I got:
../clang/test/Analysis/constant-folding.c:281:5: warning: FALSE
[debug.ExprInspection]
clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../clang/test/Analysis/constant-folding.c:281:5: warning: TRUE
[debug.ExprInspection]
clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here, `c = [INT_MIN + 1, -1]` and `d = [INT_MIN, 0]`, so `c + d = [INT_MIN, -2]
U [1, INT_MAX]`. So `c + d == 0` should be false. But in latter case, it is
reasoning `c + d == 0` to be `UNKNOWN`.
Also, the error arises in `c + d == 0` case only and not in `c + d == -1` case.
I mistakenly highlighted that case while commenting.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103440/new/
https://reviews.llvm.org/D103440
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
