RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-31 07:52:55 +01:00
Code Issues Projects Releases Wiki Activity
14683e5753
llvm-mirror/test/Transforms/SimplifyCFG/trapping-load-unreachable.ll

88 lines
1.6 KiB
LLVM
Raw Normal View History

make simplifycfg insert an llvm.trap before the 'unreachable' it introduces when it detects undefined behavior. llvm.trap generally codegens into some thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this sort of thing is "nontrivial". For example, we now compile: void foo() { *(int*)0 = 42; } into: _foo: pushl %ebp movl %esp, %ebp ud2 Some may even claim that this is a security hole, though that seems dubious to me. This addresses rdar://7958343 - Optimizing away null dereference potentially allows arbitrary code execution llvm-svn: 103356
2010-05-09 00:15:59 +02:00
; RUN: opt < %s -simplifycfg -S | FileCheck %s
Fix PR2967 by not deleting volatile load/stores that occur before unreachable. I don't really see this as being needed, but there is little harm from doing it. llvm-svn: 58385
2008-10-29 18:46:26 +01:00
; PR2967
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32"
target triple = "i386-pc-linux-gnu"
make simplifycfg insert an llvm.trap before the 'unreachable' it introduces when it detects undefined behavior. llvm.trap generally codegens into some thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this sort of thing is "nontrivial". For example, we now compile: void foo() { *(int*)0 = 42; } into: _foo: pushl %ebp movl %esp, %ebp ud2 Some may even claim that this is a security hole, though that seems dubious to me. This addresses rdar://7958343 - Optimizing away null dereference potentially allows arbitrary code execution llvm-svn: 103356
2010-05-09 00:15:59 +02:00
define void @test1(i32 %x) nounwind {
Fix PR2967 by not deleting volatile load/stores that occur before unreachable. I don't really see this as being needed, but there is little harm from doing it. llvm-svn: 58385
2008-10-29 18:46:26 +01:00
entry:
%0 = icmp eq i32 %x, 0 ; <i1> [#uses=1]
br i1 %0, label %bb, label %return
bb: ; preds = %entry
Move "atomic" and "volatile" designations on instructions after the opcode of the instruction. Note that this change affects the existing non-atomic load and store instructions; the parser now accepts both forms, and the change is noted in the release notes. llvm-svn: 137527
2011-08-13 00:50:01 +02:00
%1 = load volatile i32* null
Fix PR2967 by not deleting volatile load/stores that occur before unreachable. I don't really see this as being needed, but there is little harm from doing it. llvm-svn: 58385
2008-10-29 18:46:26 +01:00
unreachable
make simplifycfg insert an llvm.trap before the 'unreachable' it introduces when it detects undefined behavior. llvm.trap generally codegens into some thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this sort of thing is "nontrivial". For example, we now compile: void foo() { *(int*)0 = 42; } into: _foo: pushl %ebp movl %esp, %ebp ud2 Some may even claim that this is a security hole, though that seems dubious to me. This addresses rdar://7958343 - Optimizing away null dereference potentially allows arbitrary code execution llvm-svn: 103356
2010-05-09 00:15:59 +02:00
Fix PR2967 by not deleting volatile load/stores that occur before unreachable. I don't really see this as being needed, but there is little harm from doing it. llvm-svn: 58385
2008-10-29 18:46:26 +01:00
br label %return
return: ; preds = %entry
ret void
make simplifycfg insert an llvm.trap before the 'unreachable' it introduces when it detects undefined behavior. llvm.trap generally codegens into some thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this sort of thing is "nontrivial". For example, we now compile: void foo() { *(int*)0 = 42; } into: _foo: pushl %ebp movl %esp, %ebp ud2 Some may even claim that this is a security hole, though that seems dubious to me. This addresses rdar://7958343 - Optimizing away null dereference potentially allows arbitrary code execution llvm-svn: 103356
2010-05-09 00:15:59 +02:00
; CHECK: @test1
Move "atomic" and "volatile" designations on instructions after the opcode of the instruction. Note that this change affects the existing non-atomic load and store instructions; the parser now accepts both forms, and the change is noted in the release notes. llvm-svn: 137527
2011-08-13 00:50:01 +02:00
; CHECK: load volatile
make simplifycfg insert an llvm.trap before the 'unreachable' it introduces when it detects undefined behavior. llvm.trap generally codegens into some thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this sort of thing is "nontrivial". For example, we now compile: void foo() { *(int*)0 = 42; } into: _foo: pushl %ebp movl %esp, %ebp ud2 Some may even claim that this is a security hole, though that seems dubious to me. This addresses rdar://7958343 - Optimizing away null dereference potentially allows arbitrary code execution llvm-svn: 103356
2010-05-09 00:15:59 +02:00
}
; rdar://7958343
define void @test2() nounwind {
entry:
store i32 4,i32* null
ret void
; CHECK: @test2
; CHECK: call void @llvm.trap
; CHECK: unreachable
Fix PR2967 by not deleting volatile load/stores that occur before unreachable. I don't really see this as being needed, but there is little harm from doing it. llvm-svn: 58385
2008-10-29 18:46:26 +01:00
}
Test case for r105914. llvm-svn: 105915
2010-06-13 18:16:54 +02:00
; PR7369
define void @test3() nounwind {
entry:
Move "atomic" and "volatile" designations on instructions after the opcode of the instruction. Note that this change affects the existing non-atomic load and store instructions; the parser now accepts both forms, and the change is noted in the release notes. llvm-svn: 137527
2011-08-13 00:50:01 +02:00
store volatile i32 4, i32* null
Test case for r105914. llvm-svn: 105915
2010-06-13 18:16:54 +02:00
ret void
; CHECK: @test3
Move "atomic" and "volatile" designations on instructions after the opcode of the instruction. Note that this change affects the existing non-atomic load and store instructions; the parser now accepts both forms, and the change is noted in the release notes. llvm-svn: 137527
2011-08-13 00:50:01 +02:00
; CHECK: store volatile i32 4, i32* null
Test case for r105914. llvm-svn: 105915
2010-06-13 18:16:54 +02:00
; CHECK: ret
}
Update SimplifyCFG for atomic operations. This commit includes a mention of the landingpad instruction, but it's not changing the behavior around it. I think the current behavior is correct, though. Bill, can you double-check that? llvm-svn: 137691
2011-08-16 01:59:28 +02:00
; Check store before unreachable.
define void @test4(i1 %C, i32* %P) {
; CHECK: @test4
; CHECK: entry:
; CHECK-NEXT: br i1 %C
entry:
br i1 %C, label %T, label %F
T:
store volatile i32 0, i32* %P
unreachable
F:
ret void
}
; Check cmpxchg before unreachable.
define void @test5(i1 %C, i32* %P) {
; CHECK: @test5
; CHECK: entry:
; CHECK-NEXT: br i1 %C
entry:
br i1 %C, label %T, label %F
T:
cmpxchg volatile i32* %P, i32 0, i32 1 seq_cst
unreachable
F:
ret void
}
; Check atomicrmw before unreachable.
define void @test6(i1 %C, i32* %P) {
; CHECK: @test6
; CHECK: entry:
; CHECK-NEXT: br i1 %C
entry:
br i1 %C, label %T, label %F
T:
atomicrmw volatile xchg i32* %P, i32 0 seq_cst
unreachable
F:
ret void
}
Reference in New Issue Copy Permalink