| 262e0d41e49c6b823d62743535e2accb117a6ea9 |
|
15-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Re-enable using global regions as a symbolic base.
Now that we're invalidating global regions properly, we want to continue
taking advantage of a particular optimization: if all global regions are
invalidated together, we can represent the bindings of each region with
a "derived region value" symbol. Essentially, this lazily links each
global region with a single symbol created at invalidation time, rather
than binding each region with a new symbolic value.
We used to do this, but haven't been for a while; the previous commit
re-enabled this code path, and this handles the fallout.
<rdar://problem/13464044>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179554 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/global_region_invalidation.mm
|
| e0208ff84598f48e0aafecf5b543afeff8574045 |
|
15-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Properly invalidate global regions on opaque function calls.
This fixes a regression where a call to a function we can't reason about
would not actually invalidate global regions that had explicit bindings.
void test_that_now_works() {
globalInt = 42;
clang_analyzer_eval(globalInt == 42); // expected-warning{{TRUE}}
invalidateGlobals();
clang_analyzer_eval(globalInt == 42); // expected-warning{{UNKNOWN}}
}
This has probably been around since the initial "cluster" refactoring of
RegionStore, if not longer.
<rdar://problem/13464044>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179553 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/global_region_invalidation.mm
|
| f8e2c06cea1548c437761cb65cfbf97d50a057a7 |
|
20-Mar-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't invalidate globals when there's no call involved.
This fixes some mistaken condition logic in RegionStore that caused
global variables to be invalidated when /any/ region was invalidated,
rather than only as part of opaque function calls. This was only
being used by CStringChecker, and so users will now see that strcpy()
and friends do not invalidate global variables.
Also, add a test case we don't handle properly: explicitly-assigned
global variables aren't being invalidated by opaque calls. This is
being tracked by <rdar://problem/13464044>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177572 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/global_region_invalidation.mm
|
| fbdbed3bde8577815826b9d15790e5effb913f7b |
|
25-Feb-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Handle reference parameters with default values.
r175026 added support for default values, but didn't take reference
parameters into account, which expect the default argument to be an
lvalue. Use createTemporaryRegionIfNeeded if we can evaluate the default
expr as an rvalue but the expected result is an lvalue.
Fixes the most recent report of PR12915. The original report predates
default argument support, so that can't be it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176042 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/global_region_invalidation.mm
|
| 2b6876173b36d92aaf379c29cb339d91b4d358ee |
|
08-Feb-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Don't reinitialize static globals more than once along a path
This patch makes sure that we do not reinitialize static globals when
the function is called more than once along a path. The motivation is
code with initialization patterns that rely on 2 static variables, where
one of them has an initializer while the other does not. Currently, we
reset the static variables with initializers on every visit to the
function along a path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174676 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/global_region_invalidation.mm
|