martong added inline comments.
================
Comment at: clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:107
+ return makeNonLoc(X.castAs<nonloc::SymbolVal>().getSymbol(), UO_Not,
+ X.getType(Context));
default:
----------------
steakhal wrote:
> martong wrote:
> > steakhal wrote:
> > > I'm not sure if we should rely on `SVal::getType()`. I think the calling
> > > context should pass the type along here.
> > Good point. One example where the type of the SVal is different than the
> > type of the UnaryExpr is here:
> > ```
> > void test_x(int x, long y) {
> > x = y; // $x has `long` type
> > -x; // the UnaryExpr `-x` has `int` type
> > }
> > ```
> > Note that if we use `support-symbolic-integer-casts=true` then there is no
> > such type mismatch because there is in implicit cast modeled at `x = y`,
> > thus $x type is correctly `int`.
> >
> > Anyway, I am going to update evalMinus and evalComplement to take an
> > additional QualType parameter.
> Please add this test with both scenarios with
> `support-symbolic-integer-casts`. D125532 will help in demonstrating this.
Ahh, unfortunately, if we use the type of the AST's `UnaryExpr` instead of the
operand `SVal` then we will end up crashing the constraint solver, because of
the missing SymbolCast below:
```
void crash(int b, long c) {
b = c;
if (b > 0) // $b is long
if(-b) // should not crash here // $-b is int
;
// SymbolicRangeInferrer
// takes the negated range of $-b (with type int)
// getRangeForNegatedSub
// and takes the range of $b (with type long) and tries to intersect them.
// RangeSet VisitSymExpr(SymbolRef Sym)
}
```
This manifests in the child patch, because that's where we add the support of
UnarySymExpr to the solver, so I add a test case there.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D125318/new/
https://reviews.llvm.org/D125318
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
