[LLVMbugs] [Bug 18538] New: Non-static const array is wrongly shared among recursions

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Jan 18 22:05:45 PST 2014


            Bug ID: 18538
           Summary: Non-static const array is wrongly shared among
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: k_satoda at f2.dion.ne.jp
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The assertion in the following program should never fail because
variables with automatic storage duration in a function should be
created for each recursive invocation, and such distinct objects'
address should not compare equal.

  #include <assert.h>
  #include <stdio.h>
  int f(const int* p)
    const int c[] = {12345,56789};
    assert(p != c);
    if (p == 0) { return f(c); }
    return 0;
  int main()

Clang 3.3 seems violating the rule and causes an assertion failure.
> prog.exe: prog.c:6: int f(const int *): Assertion `p != c' failed.

I'm referring WG14 N1570.

>From 6.2.4 p6:
> For such an object that does not have a variable length array type, its
> lifetime extends from entry into the block with which it is associated
> until execution of that block ends in any way. (Entering an enclosed
> block or calling a function suspends, but does not end, execution of the
> current block.) If the block is entered recursively, a new instance of
> the object is created each time.

6.5.9 p6
> Two pointers compare equal if and only if both are null pointers, both
> are pointers to the same object ...

If the variable is not an array, there seems no problem.

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/20140119/fa167cf0/attachment.html>

More information about the llvm-bugs mailing list