summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] [NFC] remove duplicated functionGeorge Karpenkov2017-12-041-31/+12
| | | | | | | | | | | Two copies of getSymLERange in RangeConstraintManager are virtually identical, which is clearly bad. This patch uses lambdas to call one from another (assuming that we would like to avoid getting ranges from the state when necessary). Differential Revision: https://reviews.llvm.org/D39709 llvm-svn: 319697
* [analyzer] Don't treat lambda-captures float constexprs as undefinedDevin Coughlin2017-12-041-2/+9
| | | | | | | | | | | | | | RegionStore has special logic to evaluate captured constexpr variables. However, if the constexpr initializer cannot be evaluated as an integer, the value is treated as undefined. This leads to false positives when, for example, a constexpr float is captured by a lambda. To fix this, treat a constexpr capture that cannot be evaluated as unknown rather than undefined. rdar://problem/35784662 llvm-svn: 319638
* [analyzer] Fix false negative on post-increment of uninitialized variable.Roman Lebedev2017-11-301-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang static analyzer does warn on: ``` int x; x+=1; x-=1; x=x+1; x=x-1; ``` But does warn on: ``` int x; x++; x--; --x; ++x; ``` This differential should fix that. Fixes https://bugs.llvm.org/show_bug.cgi?id=35419 Reviewers: dcoughlin, NoQ Reviewed By: dcoughlin Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin Tags: #clang Differential Revision: https://reviews.llvm.org/D40463 llvm-svn: 319411
* [analyzer] Fix unreachable creating PathDiagnosticLocation with widen-loops=trueDevin Coughlin2017-11-291-0/+9
| | | | | | | | | | | | | In the original design of the analyzer, it was assumed that a BlockEntrance doesn't create a new binding on the Store, but this assumption isn't true when 'widen-loops' is set to true. Fix this by finding an appropriate location BlockEntrace program points. Patch by Henry Wong! Differential Revision: https://reviews.llvm.org/D37187 llvm-svn: 319333
* [analyzer] pr34766: Fix a crash on explicit std::initializer_list constructor.Artem Dergachev2017-11-271-1/+1
| | | | | | | | | | | | | | | | We didn't support the following syntax: (std::initializer_list<int>){12} which suddenly produces CompoundLiteralExpr that contains CXXStdInitializerListExpr. Lift the assertion and instead pass the value through CompoundLiteralExpr transparently, as it doesn't add much. Differential Revision: https://reviews.llvm.org/D39803 llvm-svn: 319058
* [analyzer] pr34404: Fix a crash on modeling pointers to indirect members.Artem Dergachev2017-11-271-1/+3
| | | | | | | | | | | | | | | | | We were crashing whenever a C++ pointer-to-member was taken, that was pointing to a member of an anonymous structure field within a class, eg. struct A { struct { int x; }; }; // ... &A::x; Differential Revision: https://reviews.llvm.org/D39800 llvm-svn: 319055
* Add NDEBUG checks around LLVM_DUMP_METHOD functions for Wunused-function ↵Eric Christopher2017-11-161-0/+2
| | | | | | warnings. llvm-svn: 318371
* [analyzer] [NFC] Minor ExprEngineC refactoringGeorge Karpenkov2017-11-091-15/+22
| | | | | | | | Move a repeated block of code into a function. Differential Revision: https://reviews.llvm.org/D39584 llvm-svn: 317849
* [analyzer] do not crash when trying to convert an APSInt to an unexpected typeGeorge Karpenkov2017-11-091-1/+3
| | | | | | | | | | | | | | | | | | | | This is the issue breaking the postgresql bot, purely by chance exposed through taint checker, somehow appearing after https://reviews.llvm.org/D38358 got committed. The backstory is that the taint checker requests SVal for the value of the pointer, and analyzer has a "fast path" in the getter to return a constant when we know that the value is constant. Unfortunately, the getter requires a cast to get signedness correctly, and for the pointer `void *` the cast crashes. This is more of a band-aid patch, as I am not sure what could be done here "correctly", but it should be applied in any case to avoid the crash. Differential Revision: https://reviews.llvm.org/D39862 llvm-svn: 317839
* [analyzer] assume bitwise arithmetic axiomsGeorge Karpenkov2017-11-091-6/+54
| | | | | | | | | | | | | | | Patches the solver to assume that bitwise OR of an unsigned value with a constant always produces a value larger-or-equal than the constant, and bitwise AND with a constant always produces a value less-or-equal than the constant. This patch is especially useful in the context of using bitwise arithmetic for error code encoding: the analyzer would be able to state that the error code produced using a bitwise OR is non-zero. Differential Revision: https://reviews.llvm.org/D39707 llvm-svn: 317820
* [analyzer] Fix a crash on logical operators with vectors.Artem Dergachev2017-11-081-0/+10
| | | | | | | | | | | | | | | | | Do not crash when trying to compute x && y or x || y where x and y are of a vector type. For now we do not seem to properly model operations with vectors. In particular, operations && and || on a pair of vectors are not short-circuit, unlike regular logical operators, so even our CFG is incorrect. Avoid the crash, add respective FIXME tests for later. Differential Revision: https://reviews.llvm.org/D39682 rdar://problem/34317663 llvm-svn: 317700
* [analyzer] [NFC] very minor ExprEngineC refactoringGeorge Karpenkov2017-11-031-4/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D39577 llvm-svn: 317294
* [analyzer] Use the same filename for the header and the implementation of ↵George Karpenkov2017-10-301-1/+1
| | | | | | | | BugReporterVisitor Differential Revision: https://reviews.llvm.org/D37935 llvm-svn: 316963
* [analyzer] Left shifting a negative value is undefinedGabor Horvath2017-10-301-0/+2
| | | | | | | | | | The analyzer did not return an UndefVal in case a negative value was left shifted. I also altered the UndefResultChecker to emit a clear warning in this case. Differential Revision: https://reviews.llvm.org/D39423 llvm-svn: 316924
* [analyzer] Use the signature of the primary template for issue hash calculationGabor Horvath2017-10-301-0/+7
| | | | | | | | | | | | | Now when a template is instantiated more times and there is a bug found in the instantiations the issue hash will be different for each instantiation even if every other property of the bug (path, message, location) is the same. This patch aims to resolve this issue. Note that explicit specializations still generate different hashes but that is intended. Differential Revision: https://reviews.llvm.org/D38728 llvm-svn: 316900
* [analyzer] Handle ObjC messages conservatively in CallDescriptionGabor Horvath2017-10-301-1/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D37470 llvm-svn: 316885
* [analyzer] LoopUnrolling: check the bitwidth of the used numbers (pr34943)Peter Szecsi2017-10-281-2/+9
| | | | | | | | | | | | | | | The loop unrolling feature aims to track the maximum possible steps a loop can make. In order to implement this, it investigates the initial value of the counter variable and the bound number. (It has to be known.) These numbers are used as llvm::APInts, however, it was not checked if their bitwidths are the same which lead to some crashes. This revision solves this problem by extending the "shorter" one (to the length of the "longer" one). For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943 Differential Revision: https://reviews.llvm.org/D38922 llvm-svn: 316830
* [Analyzer] Do not use static storage to for implementations created in ↵George Karpenkov2017-10-231-27/+19
| | | | | | | | BodyFarm.cpp Differential Revision: https://reviews.llvm.org/D39208 llvm-svn: 316400
* [analyzer] Fix handling of labels in getLValueElementAlexander Shaposhnikov2017-10-231-1/+4
| | | | | | | | | | | In getLValueElement Base may represent the address of a label (as in the newly-added test case), in this case it's not a loc::MemRegionVal and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes getLValueElement return UnknownVal instead. Differential revision: https://reviews.llvm.org/D39174 llvm-svn: 316399
* [analyzer] Dump signed integers in SymIntExpr and IntSymExpr correctlyGabor Horvath2017-10-191-3/+9
| | | | | | | | Patch by: Adam Balogh! Differential Revision: https://reviews.llvm.org/D39048 llvm-svn: 316157
* [analyzer] pr28449: Fix support for various array initializers.Artem Dergachev2017-10-131-8/+5
| | | | | | | | | | | | | | | | | | In some cases the analyzer didn't expect an array-type variable to be initialized with anything other than a string literal. The patch essentially removes the assertion, and ensures relatively sane behavior. There is a bigger problem with these initializers. Currently our memory model (RegionStore) is being ordered to initialize the array with a region that is assumed to be storing the initializer rvalue, and it guesses to copy the contents of that region to the array variable. However, it would make more sense for RegionStore to receive the correct initializer in the first place. This problem isn't addressed with this patch. rdar://problem/27248428 Differential Revision: https://reviews.llvm.org/D23963 llvm-svn: 315750
* SVal::getAsSymbol(bool IncludeBaseRegions): Follow ↵NAKAMURA Takumi2017-10-121-2/+2
| | | | | | clang/StaticAnalyzer/Core/PathSensitive/SVals.h, s/IncludeBaseRegion/IncludeBaseRegions/g [-Wdocumentation] llvm-svn: 315572
* [Analyzer] Clarify error messages for undefined resultDaniel Marjamaki2017-10-111-0/+32
| | | | | | Differential Revision: https://reviews.llvm.org/D30295 llvm-svn: 315462
* [analyzer] Implement pointer arithmetic on constantsGabor Horvath2017-10-101-0/+6
| | | | | | | | Patch by: Rafael Stahl! Differential Revision: https://reviews.llvm.org/D37478 llvm-svn: 315296
* [analyzer] Fix leak false positives on stuff put in C++/ObjC initializer lists.Artem Dergachev2017-10-051-17/+38
| | | | | | | | | | | | | | | The analyzer now realizes that C++ std::initializer_list objects and Objective-C boxed structure/array/dictionary expressions can potentially maintain a reference to the objects that were put into them. This avoids false memory leak posivites and a few other issues. This is a conservative behavior; for now, we do not model what actually happens to the objects after being passed into such initializer lists. rdar://problem/32918288 Differential Revision: https://reviews.llvm.org/D35216 llvm-svn: 314975
* [analyzer] Fix autodetection of binding types.Artem Dergachev2017-10-041-8/+11
| | | | | | | | | | | | | | | | | | | | | | | In ProgramState::getSVal(Location, Type) API which dereferences a pointer value, when the optional Type parameter is not supplied and the Location is not typed, type should have been guessed on a best-effort basis by inspecting the Location more deeply. However, this never worked; the auto-detected type was instead a pointer type to the correct type. Fixed the issue and added various test cases to demonstrate which parts of the analyzer were affected (uninitialized pointer argument checker, C++ trivial copy modeling, Google test API modeling checker). Additionally, autodetected void types are automatically replaced with char, in order to simplify checker APIs. Which means that if the location is a void pointer, getSVal() would read the first byte through this pointer and return its symbolic value. Fixes pr34305. Differential Revision: https://reviews.llvm.org/D38358 llvm-svn: 314910
* [analyzer] Match more patterns in bugreporter::getDerefExpr() API.Artem Dergachev2017-09-271-5/+17
| | | | | | | | | | This function can now track null pointer through simple pointer arithmetic, such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces for the user to understand where the null pointer is coming from. Differential Revision: https://reviews.llvm.org/D37025 llvm-svn: 314290
* [analyzer] Fix and refactor bugreporter::getDerefExpr() API.Artem Dergachev2017-09-271-30/+50
| | | | | | | | | | | | | | | | | | | | This API is used by checkers (and other entities) in order to track where does a value originate from, by jumping from an expression value of which is equal to that value to the expression from which this value has "appeared". For example, it may be an lvalue from which the rvalue was loaded, or a function call from which the dereferenced pointer was returned. The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts, which caused crashes and incorrect intermediate diagnostic pieces. It also no longer relies on how the expression is written when guessing what it means. Fixes pr34373 and pr34731. rdar://problem/33594502 Differential Revision: https://reviews.llvm.org/D37023 llvm-svn: 314287
* [analyzer] Fix crash on modeling of pointer arithmeticAlexander Shaposhnikov2017-09-251-3/+5
| | | | | | | | | | | | | | | | | | | This patch fixes analyzer's crash on the newly added test case (see also https://bugs.llvm.org/show_bug.cgi?id=34374). Pointers subtraction appears to be modeled incorrectly in the following example: char* p; auto n = p - reinterpret_cast<char*>((unsigned long)1); In this case the analyzer (built without this patch) tries to create a symbolic value for the difference treating reinterpret_cast<char*>((unsigned long)1) as an integer, that is not correct. Differential revision: https://reviews.llvm.org/D38214 Test plan: make check-all llvm-svn: 314141
* [Analyzer] Log when auto-synthesized body is used.George Karpenkov2017-09-221-3/+14
| | | | | | Differential Revision: https://reviews.llvm.org/D37910 llvm-svn: 313944
* [CSA] [NFC] Move AnalysisContext.h to AnalysisDeclContext.hGeorge Karpenkov2017-09-064-4/+4
| | | | | | | | | | | | | | The implementation is in AnalysisDeclContext.cpp and the class is called AnalysisDeclContext. Making those match up has numerous benefits, including: - Easier jump from header to/from implementation. - Easily identify filename from class. Differential Revision: https://reviews.llvm.org/D37500 llvm-svn: 312671
* [NFC] [CSA] Move AnyFunctionCall::getRuntimeDefinition implementation to cpp.George Karpenkov2017-09-061-0/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D37499 llvm-svn: 312670
* Removed dead code (PR34467). NFCI.Simon Pilgrim2017-09-051-3/+0
| | | | | | The for loop already checks that Idx < NumOfArgs. llvm-svn: 312525
* Remove trailing space.Rui Ueyama2017-08-281-3/+3
| | | | llvm-svn: 311936
* [analyzer] Fix crash in modeling arithmeticAlexander Shaposhnikov2017-08-281-0/+8
| | | | | | | | | | | | | This diff fixes modeling of arithmetic expressions where pointers are treated as integers (i.e. via C-style / reinterpret casts). For now we return UnknownVal unless the operation is a comparison. Test plan: make check-all Differential revision: https://reviews.llvm.org/D37120 llvm-svn: 311935
* [StaticAnalyzer] LoopUnrolling: Keep track the maximum number of steps for ↵Peter Szecsi2017-08-282-31/+57
| | | | | | | | | | | | each loop This way the unrolling can be restricted for loops which will take at most a given number of steps. It is defined as 128 in this patch and it seems to have a good number for that purpose. Differential Revision: https://reviews.llvm.org/D37181 llvm-svn: 311883
* [StaticAnalyzer] LoopUnrolling: Excluding loops which splits the statePeter Szecsi2017-08-281-1/+26
| | | | | | | | | | Added check if the execution of the last step of the given unrolled loop has generated more branches. If yes, than treat it as a normal (non-unrolled) loop in the remaining part of the analysis. Differential Revision: https://reviews.llvm.org/D36962 llvm-svn: 311881
* [StaticAnalyzer] LoopUnrolling fixesPeter Szecsi2017-08-283-12/+10
| | | | | | | | | | | | | | 1. The LoopUnrolling feature needs the LoopExit included in the CFG so added this dependency via the config options 2. The LoopExit element can be encountered even if we haven't encountered the block of the corresponding LoopStmt. So the asserts were not right. 3. If we are caching out the Node then we get a nullptr from generateNode which case was not handled. Differential Revision: https://reviews.llvm.org/D37103 llvm-svn: 311880
* [StaticAnalyzer] LoopUnrolling: Track a LoopStack in order to completely ↵Peter Szecsi2017-08-212-96/+82
| | | | | | | | | | | | | unroll specific loops The LoopExit CFG information provides the opportunity to not mark the loops but having a stack which tracks if a loop is unrolled or not. So in case of simulating a loop we just add it and the information if it meets the requirements to be unrolled to the top of the stack. Differential Revision: https://reviews.llvm.org/D35684 llvm-svn: 311346
* [StaticAnalyzer] Handle LoopExit CFGElement in the analyzerPeter Szecsi2017-08-212-3/+28
| | | | | | | | | | This patch adds handling of the LoopExit CFGElements to the StaticAnalyzer. This is reached by introducing a new ProgramPoint. Tests will be added in a following commit. Differential Revision: https://reviews.llvm.org/D35670 llvm-svn: 311344
* [CFG] Add LoopExit information to CFGPeter Szecsi2017-08-194-2/+11
| | | | | | | | | | | | | | | | This patch introduces a new CFG element CFGLoopExit that indicate when a loop ends. It does not deal with returnStmts yet (left it as a TODO). It hidden behind a new analyzer-config flag called cfg-loopexit (false by default). Test cases added. The main purpose of this patch right know is to make loop unrolling and loop widening easier and more efficient. However, this information can be useful for future improvements in the StaticAnalyzer core too. Differential Revision: https://reviews.llvm.org/D35668 llvm-svn: 311235
* [StaticAnalyzer] LoopUnrolling: Exclude cases where the counter is escaped ↵Peter Szecsi2017-08-192-37/+84
| | | | | | | | | | | before the loop Adding escape check for the counter variable of the loop. It is achieved by jumping back on the ExplodedGraph to its declStmt. Differential Revision: https://reviews.llvm.org/D35657 llvm-svn: 311234
* [analyzer] Fix modeling of constructorsAlexander Shaposhnikov2017-08-181-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | This diff fixes analyzer's crash (triggered assert) on the newly added test case. The assert being discussed is assert(!B.lookup(R, BindingKey::Direct)) in lib/StaticAnalyzer/Core/RegionStore.cpp, however the root cause is different. For classes with empty bases the offsets might be tricky. For example, let's assume we have struct S: NonEmptyBase, EmptyBase { ... }; In this case Clang applies empty base class optimization and the offset of EmptyBase will be 0, it can be verified via clang -cc1 -x c++ -v -fdump-record-layouts main.cpp -emit-llvm -o /dev/null. When the analyzer tries to perform zero initialization of EmptyBase it will hit the assert because that region has already been "written" by the constructor of NonEmptyBase. Test plan: make check-all Differential revision: https://reviews.llvm.org/D36851 llvm-svn: 311182
* [analyzer] Fix SimpleSValBuilder::simplifySValAlexander Shaposhnikov2017-08-141-1/+2
| | | | | | | | | | This diff fixes a crash (triggered assert) on the newly added test case. In the method Simplifier::VisitSymbolData we check the type of S and return Loc/NonLoc accordingly. Differential revision: https://reviews.llvm.org/D36564 llvm-svn: 310887
* [analyzer] Rename functions responsible for CFG-based suppress-on-sink.Artem Dergachev2017-08-141-13/+21
| | | | | | | | | Update comments. No functional change intended. Addresses Devin's post-commit review comments in https://reviews.llvm.org/D35673 and https://reviews.llvm.org/D35674. llvm-svn: 310820
* [Analyzer] Add support for displaying cross-file diagnostic paths in HTML outputDevin Coughlin2017-08-031-105/+209
| | | | | | | | | | | This change adds support for cross-file diagnostic paths in html output. If the diagnostic path is not cross-file, there is no change in the output. Patch by Vlad Tsyrklevich! Differential Revision: https://reviews.llvm.org/D30406 llvm-svn: 309968
* [StaticAnalyzer] LoopUnrolling - Attempt #2 to fix a crash in r309006.Peter Szecsi2017-07-251-2/+2
| | | | llvm-svn: 309061
* [StaticAnalyzer] LoopUnrolling - Attempt to fix a crash in r309006.Peter Szecsi2017-07-251-1/+3
| | | | llvm-svn: 309036
* [StaticAnalyzer] Completely unrolling specific loops with known bound optionPeter Szecsi2017-07-254-0/+237
| | | | | | | | | | | | | | | | | This feature allows the analyzer to consider loops to completely unroll. New requirements/rules (for unrolling) can be added easily via ASTMatchers. Right now it is hidden behind a flag, the aim is to find the correct heuristic and create a solution which results higher coverage % and more precise analysis, thus can be enabled by default. Right now the blocks which belong to an unrolled loop are marked by the LoopVisitor which adds them to the ProgramState. Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is marked then we skip its investigating. That means, it won't be considered to be visited more than the maximal bound for visiting since it won't be checked. llvm-svn: 309006
* [analyzer] Treat throws as sinks for suppress-on-sink purposes.Artem Dergachev2017-07-251-2/+23
| | | | | | | | | | | | | Because since r308957 the suppress-on-sink feature contains its own mini-analysis, it also needs to become aware that C++ unhandled exceptions cause sinks. Unfortunately, for now we treat all exceptions as unhandled in the analyzer, so suppress-on-sink needs to do the same. rdar://problem/28157554 Differential Revision: https://reviews.llvm.org/D35674 llvm-svn: 308961
OpenPOWER on IntegriCloud