[llvm-bugs] [Bug 32163] New: Scope context issues with variables.

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Mar 7 01:56:46 PST 2017


http://bugs.llvm.org/show_bug.cgi?id=32163

            Bug ID: 32163
           Summary: Scope context issues with variables.
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: noqnoqneo at gmail.com
                CC: llvm-bugs at lists.llvm.org

This report is made in order to document a couple of issues which should
ideally be fixed by https://reviews.llvm.org/D19979 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170307/458149c0/attachment.html>


More information about the llvm-bugs mailing list