RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 16:33:37 +01:00
Code Issues Projects Releases Wiki Activity
348c3f8197
llvm-mirror/test/Transforms/SimplifyCFG/trapping-load-unreachable.ll

45 lines
905 B
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
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
%1 = volatile load 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
; CHECK: volatile load
}
; 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:
volatile store i32 4, i32* null
ret void
; CHECK: @test3
; CHECK: volatile store i32 4, i32* null
; CHECK: ret
}
Reference in New Issue Copy Permalink