[LLVMbugs] [Bug 20404] New: clang: inconsistent behaviour of alloca

[bugzilla-daemon at llvm.org]

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

            Bug ID: 20404
           Summary: clang: inconsistent behaviour of alloca
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dbrazdil at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12809
  --> http://llvm.org/bugs/attachment.cgi?id=12809&action=edit
Source code

Compiling the following piece of code with the trunk version of LLVM/Clang
yields different results with/without optimization turned on and also with
Debug/Release builds.

    #include <sys/types.h>
    #include <stdlib.h>

    int main() {
      return (int) alloca((int32_t) -1);
    }

With -O0, the intermediate representation sign-extends the alloca argument to
i64 negative one:

    define i32 @main() #0 {
      %1 = alloca i32, align 4
      store i32 0, i32* %1
      %2 = alloca i8, i64 -1
      %3 = ptrtoint i8* %2 to i32
      ret i32 %3
    }

With the debug build, the code generator hits the
'!isDeadObjectIndex(ObjectIdx)' assertion inside
MachineFrameInfo::getObjectOffset and fails. However, with the release build it
produces the following code where the offset in LEAQ overflowed and wrapped
around:

    pushq   %rbp
    movq    %rsp, %rbp
    leaq    16(%rbp), %rax
    movl    $0, -4(%rbp)
    movl    %eax, %ecx
    movl    %ecx, %eax
    popq    %rbp
    retq

Turning on optimizations modifies the type of the alloca to an i8 array, but
its size gets interpreted as an unsigned integer and becomes (2^64 - 1):

    define i32 @main() #0 {
      %1 = alloca [18446744073709551615 x i8], align 1
      %2 = ptrtoint [18446744073709551615 x i8]* %1 to i64
      %3 = trunc i64 %2 to i32
      ret i32 %3
    }

Both the debug and release build then enter the while loop inside
X86FrameLowering::emitSPUpdate and keep producing ADD instructions which push
the stack pointer by ((1<<31)-1) until the machine runs out of memory.

-- 
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/20140722/d8520627/attachment.html>