[LLVMbugs] [Bug 11930] New: Bug in code generation for v8qi initialization with uint32 causes stack corruption

[bugzilla-daemon at llvm.org]

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

             Bug #: 11930
           Summary: Bug in code generation for v8qi initialization with
                    uint32 causes stack corruption
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: fgp at phlo.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang++ compiles the following code fragment 

  typedef char vec_t __attribute__ ((__ext_vector_type__ (8)));
  void h() {
    vec_t v(0);
  }

to

  define void @_Z1hv() nounwind uwtable {
    %v = alloca <8 x i8>, align 8
    store <8 x i32> zeroinitializer, <8 x i8>* %v, align 8
    ret void
  }

which seems wrong - only 8 bytes are allocated for $v on the stack, yet 32
bytes are written. This example was distilled for a real application which
segfaulted when built with -O0 (funnily enough, at higher optimization levels
things worked. My guess is that the offending variable was removed alltogether,
and replaced by a constant)

If one casts the integral constant (0) to the vector's element type before
passing it to the vector's constructor as in

  typedef char vec_t __attribute__ ((__ext_vector_type__ (8)));
  void h() {
    vec_t v(char(0));
  }

things work correctly. The generated code is then

  define void @_Z1hv() nounwind uwtable {
    %v = alloca <8 x i8>, align 8
    store <8 x i8> zeroinitializer, <8 x i8>* %v, align 8
    ret void
  }

i.e. the store size is now 8 bytes, not 32.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.