[llvm-bugs] [Bug 30229] New: Clang generates stacksave/stackrestore incorrectly when a loop has VLA and alloca

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=30229

            Bug ID: 30229
           Summary: Clang generates stacksave/stackrestore incorrectly
                    when a loop has VLA and alloca
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bluechristlove at 163.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider the following case:

#include <alloca.h>
#include <string.h>
#include <new>
int main(void) {
   char *cp = 0;
   for (int i = 1; i <= 100; ++i) {
      char vla[i];
      memset(vla, 0, static_cast<size_t>(i));
      if (!cp) cp = new (alloca(1)) char('Q');
   }
   return *cp == 'Q' ? 55 : 66;
}

Expected return code 55.

Clang emit LLVM IR:
we sill generate @llvm.stackstore and @llvm.stacksave. However, from GCC 6, the
VLA scope is changed when the block has alloca function:
see: https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

Space allocated with alloca exists until the containing function returns. The
space for a variable-length array is deallocated as soon as the array name's
scope ends, unless you also use alloca in this scope.

Clang should consider this condition. GCC 6 passes this case but Clang failed.

Similar bug: https://llvm.org/bugs/show_bug.cgi?format=multiple&id=16099

-- 
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/20160901/19a3128f/attachment-0001.html>