[PATCH] D31289: [analyzer] Fix symbolication for unknown unary increment/decrement results.
Phabricator via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Mar 28 09:09:40 PDT 2017
This revision was automatically updated to reflect the committed changes.
Closed by commit rL298927: [analyzer] Fix symbolication for unknown unary increment/decrement results. (authored by dergachev).
Changed prior to commit:
https://reviews.llvm.org/D31289?vs=92812&id=93251#toc
Repository:
rL LLVM
https://reviews.llvm.org/D31289
Files:
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp
cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
cfe/trunk/test/Analysis/casts.c
Index: cfe/trunk/test/Analysis/casts.c
===================================================================
--- cfe/trunk/test/Analysis/casts.c
+++ cfe/trunk/test/Analysis/casts.c
@@ -118,3 +118,8 @@
extern float globalFloat;
clang_analyzer_eval(globalFloat); // expected-warning{{UNKNOWN}}
}
+
+void locAsIntegerCasts(void *p) {
+ int x = (int) p;
+ clang_analyzer_eval(++x < 10); // no-crash // expected-warning{{UNKNOWN}}
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===================================================================
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -1054,7 +1054,7 @@
// Conjure a new symbol if necessary to recover precision.
if (Result.isUnknown()){
DefinedOrUnknownSVal SymVal =
- svalBuilder.conjureSymbolVal(nullptr, Ex, LCtx,
+ svalBuilder.conjureSymbolVal(nullptr, U, LCtx,
currBldrCtx->blockCount());
Result = SymVal;
Index: cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===================================================================
--- cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -362,6 +362,9 @@
resultTy);
case nonloc::ConcreteIntKind: {
// Transform the integer into a location and compare.
+ // FIXME: This only makes sense for comparisons. If we want to, say,
+ // add 1 to a LocAsInteger, we'd better unpack the Loc and add to it,
+ // then pack it back into a LocAsInteger.
llvm::APSInt i = rhs.castAs<nonloc::ConcreteInt>().getValue();
BasicVals.getAPSIntType(Context.VoidPtrTy).apply(i);
return evalBinOpLL(state, op, lhsL, makeLoc(i), resultTy);
@@ -942,6 +945,8 @@
rhs = convertToArrayIndex(rhs).castAs<NonLoc>();
SVal index = UnknownVal();
const MemRegion *superR = nullptr;
+ // We need to know the type of the pointer in order to add an integer to it.
+ // Depending on the type, different amount of bytes is added.
QualType elementType;
if (const ElementRegion *elemReg = dyn_cast<ElementRegion>(region)) {
@@ -955,6 +960,10 @@
assert(op == BO_Add || op == BO_Sub);
index = (op == BO_Add) ? rhs : evalMinus(rhs);
superR = region;
+ // TODO: Is this actually reliable? Maybe improving our MemRegion
+ // hierarchy to provide typed regions for all non-void pointers would be
+ // better. For instance, we cannot extend this towards LocAsInteger
+ // operations, where result type of the expression is integer.
if (resultTy->isAnyPointerType())
elementType = resultTy->getPointeeType();
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D31289.93251.patch
Type: text/x-patch
Size: 2807 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170328/8341e7d7/attachment.bin>
More information about the cfe-commits
mailing list