[LLVMbugs] [Bug 18557] New: Local object should have unique address

[bugzilla-daemon at llvm.org]

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

            Bug ID: 18557
           Summary: Local object should have unique address
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sam at rfc1149.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 11905
  --> http://llvm.org/bugs/attachment.cgi?id=11905&action=edit
Function exhibiting the problem

[version set as "unspecified" because "3.4" does not appear in the version
selector but this happens in 3.4]

The following function

int f(int recurse, const int old[]) {
  const int a[] = {1, 2, 3, 4};
  if (recurse)
    return f(0, a);
  return a == old;
}

should always return 0 (and does so in GCC):

* If `recurse' is 0, then the newly created object `a' cannot have the same
address as `old'. LLVM makes the comparison and returns the right result, which
is not faulty but may be unnecessary.

* If `recurse' is non-0, then `a' in the first invocation and `a' in the
recursive one cannot be equal, as each automatic variable must have its own
unique address as long as it is alive. Here, LLVM returns 1 without checking
instead of 0. The problem is likely that `a' is stored in `.rodata' (then
discarded as unused) while it should not be shared between `f' can be invoked
recursively and the address of `a' escapes its defining function through the
function call.

Note that this bug was found while signaling a bug on GCC which misses an
optimization when there is no such recursive call:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863

-- 
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/20140120/b50002d2/attachment.html>