llvm-6502/test/Transforms/ScalarRepl/2011-10-22-VectorCrash.ll
Cameron Zwarich 90747e34e6 The element insertion code in scalar replacement doesn't handle incorrect
element types, even though the element extraction code does. It is surprising
that this bug has been here for so long. Fixes <rdar://problem/10318778>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142740 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-23 07:02:10 +00:00

20 lines
657 B
LLVM

; RUN: opt < %s -S -scalarrepl | FileCheck %s
target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:32:64-v128:32:128-a0:0:32-n32-S32"
target triple = "thumbv7-apple-ios5.0.0"
%union.anon = type { <4 x float> }
; CHECK: @test
; CHECK-NOT: alloca
define void @test() nounwind {
entry:
%u = alloca %union.anon, align 16
%u164 = bitcast %union.anon* %u to [4 x i32]*
%arrayidx165 = getelementptr inbounds [4 x i32]* %u164, i32 0, i32 0
store i32 undef, i32* %arrayidx165, align 4
%v186 = bitcast %union.anon* %u to <4 x float>*
store <4 x float> undef, <4 x float>* %v186, align 16
ret void
}