| 651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a.
Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Analysis/stackaddrleak.c
|
| 112344ab7f96cf482bce80530676712c282756d5 |
|
01-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
Re-apply "[analyzer] Model casts to bool differently from other numbers."
This doesn't appear to be the cause of the slowdown. I'll have to try a
manual bisect to see if there's really anything there, or if it's just
the bot itself taking on additional load. Meanwhile, this change helps
with correctness.
This changes an assertion and adds a test case, then re-applies r180638,
which was reverted in r180714.
<rdar://problem/13296133> and PR15863
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180864 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 7e6b564d59df6c0594bc3a577f33536850290dec |
|
29-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
Revert "[analyzer] Model casts to bool differently from other numbers."
This seems to be causing quite a slowdown on our internal analyzer bot,
and I'm not sure why. Needs further investigation.
This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180714 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 5e6c06bc7deaaefe130b730032a9acb9cd38bf0c |
|
26-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Model casts to bool differently from other numbers.
Casts to bool (and _Bool) are equivalent to checks against zero,
not truncations to 1 bit or 8 bits.
This improved reasoning does cause a change in the behavior of the alpha
BoolAssignment checker. Previously, this checker complained about statements
like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since
that conversion is well-defined. It's hard to say what the "best" behavior
here is: this conversion is safe, but might be better written as an explicit
comparison against zero.
More usefully, besides improving our model of booleans, this fixes spurious
warnings when returning the address of a local variable cast to bool.
<rdar://problem/13296133>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180638 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 63bc186d6ac0b44ba4ec6fccb5f471b05c79b666 |
|
15-Nov-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Report leaks at the closing brace of a function body.
This fixes a few cases where we'd emit path notes like this:
+---+
1| v
p = malloc(len);
^ |2
+---+
In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168070 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| c4d2c9074be6eb2091086eddd6c8f052f3b245c8 |
|
28-Feb-2011 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[analyzer] Remove '-analyzer-check-objc-mem' flag, the nominee for best misnomer award.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126676 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 103487088211c13ff3ae66f265130c56fb6be025 |
|
28-Feb-2011 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[analyzer] Migrate BuiltinFunctionChecker to CheckerV2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126611 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| b8d545ca06761ce779eb14326af7b2dfeb1196fc |
|
25-Feb-2011 |
Ted Kremenek <kremenek@apple.com> |
Update test cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126523 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 027a6abdd6cedc0b8203da72eed6d15c796dce9d |
|
15-Feb-2011 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[analyzer] Use the new registration mechanism on some of the internal checks. These are:
StackAddrLeakChecker
ObjCAtSyncChecker
UnixAPIChecker
MacOSXAPIChecker
The rest have/create implicit dependencies between checkers and need to be handled differently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125559 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| a8166156a6414ddd6a68514dc4f48e95d2259977 |
|
17-Jun-2010 |
Ted Kremenek <kremenek@apple.com> |
Tweak stack address checker to report multiple cases where globals may reference stack memory.
Also refactor the diagnostics so that we print out the kind of stack memory returned.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106210 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 551bd1f9191af0eecdc29764e34e01803c73ae31 |
|
17-Jun-2010 |
Ted Kremenek <kremenek@apple.com> |
Rework StackAddrLeakChecker to find stores of stack memory addresses to global variables
by inspecting the Store bindings instead of iterating over all the global variables
in a translation unit. By looking at the store directly, we avoid cases where we cannot
directly load from the global variable, such as an array (which can result in an assertion failure)
and it also catches cases where we store stack addresses to non-scalar globals.
Also, but not iterating over all the globals in the translation unit, we maintain cache
locality, and the complexity of the checker becomes restricted to the complexity of the
analyzed function, and doesn't scale with the size of the translation unit.
This fixes PR 7383.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106184 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 9b1468311d625ac8920adda5440ce8ffb1a5a5d2 |
|
09-Jun-2010 |
Zhongxing Xu <xuzhongxing@gmail.com> |
Merge StackAddrLeakChecker and ReturnStackAddressChecker.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105687 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 2c46458d4cd96a3a33e8810e95e692d8e2e05ff3 |
|
09-Jun-2010 |
Zhongxing Xu <xuzhongxing@gmail.com> |
Directly compare the StackFrameContext. This greatly simplifies logic and
improves generality. Thanks Ted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105686 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|
| 1622a547971cee50e386b4cdfe62ed1fcee1036d |
|
08-Jun-2010 |
Zhongxing Xu <xuzhongxing@gmail.com> |
Add a checker check if a global variable holds a local variable's address after
the function call is left where the local variable is declared.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105602 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/stackaddrleak.c
|