<html>
<head>
<base href="http://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Scope context issues with variables."
href="http://bugs.llvm.org/show_bug.cgi?id=32163">32163</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Scope context issues with variables.
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Static Analyzer
</td>
</tr>
<tr>
<th>Assignee</th>
<td>kremenek@apple.com
</td>
</tr>
<tr>
<th>Reporter</th>
<td>noqnoqneo@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>This report is made in order to document a couple of issues which should
ideally be fixed by <a href="https://reviews.llvm.org/D19979">https://reviews.llvm.org/D19979</a> or a similar approach.
Test case 1:
int *arr[2];
void foo() {
for (int i = 0; i < 2; ++i) {
int x;
arr[i] = &x;
}
clang_analyzer_eval(arr[0] == arr[1]); // expected-warning{{UNKNOWN}}
}
Test case 2:
int *arr[2];
void bar(int i) {
int x;
arr[i] = &x;
}
void foo() {
for (int i = 0; i < 2; ++i)
bar(i);
clang_analyzer_eval(arr[0] == arr[1]); // expected-warning{{UNKNOWN}}
}
We currently yield TRUE in both cases, which is wrong because different
instances of local variable `x' may have different addresses on the stack.
The analyzer discriminates between different instances of the same AST variable
by assigning them to different memory space superregions (or block data
regions, which are not technically memory spaces) - in this case, different
instances of StackLocalsSpaceRegion.
In test 2, these instances should be different because they are constructed
with different StackFrameContext objects. However, because StackFrameContext
doesn't include a block count on the call site, but only the call expression
itself, they accidentally coincide. We could fix this by adding block count to
StackFrameContext.
In test 1, it's harder because the stack frame is the same. We'd need a
full-featured ScopeContext to fix this properly, so that the analyzer realized
that we're in different scopes on every loop iteration; i don't see an easier
fix. That'd fix test 2 automagically - the StackFrameContext instances would be
different because their parent ScopeContext instances would be different.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>