7f79b78351af03a392ee16d8ec557d47746c33c6 |
|
04-Jul-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Make sure that inlined defensive checks work on div by zero. This suppresses a false positive in std::hash_map. Fixes radar://14255587. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185608 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
2faee99ab67105e834d11df7db80a78a3e3ed37b |
|
03-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Check the stack frame when looking for a var's initialization. FindLastStoreBRVisitor is responsible for finding where a particular region gets its value; if the region is a VarRegion, it's possible that value was assigned at initialization, i.e. at its DeclStmt. However, if a function is called recursively, the same DeclStmt may be evaluated multiple times in multiple stack frames. FindLastStoreBRVisitor was not taking this into account and just picking the first one it saw. <rdar://problem/13787723> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180997 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
702077f14100f2d7acdb12ad49b53e64efc37d72 |
|
03-Apr-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Allow tracknullOrUndef look through the ternary operator even when condition is unknown Improvement of r178684 and r178685. Jordan has pointed out that I should not rely on the value of the condition to know which expression branch has been taken. It will not work in cases the branch condition is an unknown value (ex: we do not track the constraints for floats). The better way of doing this would be to find out if the current node is the right or left successor of the node that has the ternary operator as a terminator (which is how this is done in other places, like ConditionBRVisitor). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178701 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
cabc3fddae63f5eb3bd44bdecce7a3fbd69421a9 |
|
03-Apr-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] make peelOffOuterExpr in BugReporterVisitors recursively peel off select Exprs git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178685 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
c1bef5671e682de5a573c7c6b66871b36de0ec61 |
|
03-Apr-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Properly handle the ternary operator in trackNullOrUndefValue 1) Look for the node where the condition expression is live when checking if it is constrained to true or false. 2) Fix a bug in ProgramState::isNull, which was masking the problem. When the expression is not a symbol (,which is the case when it is Unknown) return unconstrained value, instead of value constrained to “false”! (Thankfully other callers of isNull have not been effected by the bug.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178684 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
f510f5cd57fa9b7ea6f6e103c65c0df95a55d986 |
|
16-Mar-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] BugReporterVisitors: handle the case where a ternary operator is wrapped in a cast. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177205 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
dc9c160dede7e2f5cc11755db6aaa57e7fccbcec |
|
15-Mar-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Teach trackNullOrUndef to look through ternary operators Allows the suppression visitors trigger more often. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177137 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
6f4160828db75f36b22a204da202723c592644f3 |
|
27-Feb-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176201 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
6a329ee7567cf3267ffab2bc755ea8c773d967e7 |
|
29-Oct-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166941 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|
b9d4e5e3bb235f1149e99d3c833ff7cb3474c9f1 |
|
22-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164449 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/false-positive-suppression.c
|