GVN: deletes call to _Unwind_Resume causing C++ programs with EH to crash

[edwintorok]

Bugzilla Link	4588
Resolution	INVALID
Resolved on	Jul 20, 2009 02:15
Version	unspecified
OS	Linux
Blocks	llvm/llvm-project#4957
Attachments	bugpoint-tooptimize.bc, x.bc, api.i
CC	@asl,@lattner

Extended Description

I have reduced the crash in luxconsole on startup with -O1, it is GVN's fault, it completely deletes the loads from %eh_*, thus causing a subsequent DSE pass to delete the stores too, which causes the program to crash on startup when this code is reached.

--- bugpoint-tooptimize.ll 2009-07-20 00:02:30.000000000 +0300
+++ opt.ll 2009-07-20 00:03:08.000000000 +0300
@@ -1,4 +1,4 @@
-; ModuleID = 'bugpoint-tooptimize.bc'
+; ModuleID = 'opt.bc'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-unknown-linux-gnu"
type { i64, i64 } ; type %0
@@ -1386,12 +1386,12 @@

define void @​_Z6foobarv() {
entry:

• %save_filt.1054 = alloca i64 ; <i64*> [#uses=2]
• %save_eptr.1053 = alloca i8* ; <i8**> [#uses=2]
• %save_filt.1054 = alloca i64 ; <i64*> [#uses=1]
• %save_eptr.1053 = alloca i8* ; <i8*> [#uses=1]
  %ss = alloca %"struct.std::basic_stringstream<char,std::char_traits,std::allocator >" ; <%"struct.std::basic_stringstream<char,std::char_traits,std::allocator >"> [#uses=4]
  %td = alloca %"struct.boost::posix_time::time_duration" ; <%"struct.boost::posix_time::time_duration"*> [#uses=2]
• %eh_exception = alloca i8* ; <i8**> [#uses=7]
• %eh_selector = alloca i64 ; <i64*> [#uses=4]
• %eh_exception = alloca i8* ; <i8**> [#uses=3]

• %eh_selector = alloca i64 ; <i64> [#uses=3]
  %"alloca point" = bitcast i32 0 to i32 ; [#uses=0]
  call void @​_ZN5boost10posix_time13time_durationC1Eiiil(%"struct.boost::posix_time::time_duration" %td, i32 0, i32 0, i32 1, i64 0)
  %0 = call i32 @​_ZStorSt13_IosOpenmodeS(i32 16, i32 8) nounwind ; [#uses=1]
  @@ -1405,55 +1405,30 @@

  invcont: ; preds = %entry
  call void @​_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev(%"struct.std::basic_stringstream<char,std::char_traits,std::allocator >"* %ss)

• br label %return

• -bb: ; preds = %ppad

• %eh_select = load i64* %eh_selector ; [#uses=1]
• store i64 %eh_select, i64* %save_filt.1054, align 8
• %eh_value = load i8* %eh_exception ; <i8> [#uses=1]
• store i8* %eh_value, i8** %save_eptr.1053, align 8
• invoke void @​_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev(%"struct.std::basic_stringstream<char,std::char_traits,std::allocator >"* %ss)
• to label %invcont1 unwind label %lpad5

• -invcont1: ; preds = %bb

• %6 = load i8* %save_eptr.1053, align 8 ; <i8> [#uses=1]
• store i8* %6, i8** %eh_exception, align 8
• %7 = load i64* %save_filt.1054, align 8 ; [#uses=1]
• store i64 %7, i64* %eh_selector, align 8
• br label %Unwind
• ret void

-bb2: ; preds = %ppad9

• call void @​_ZSt9terminatev() noreturn nounwind
  +invcont1: ; preds = %lpad
• store i8* %eh_ptr, i8** %eh_exception, align 8
• store i64 %eh_select4, i64* %eh_selector, align 8
• call void @​_Unwind_Resume(i8* %eh_ptr)
  unreachable

-return: ; preds = %invcont

• ret void

• lpad: ; preds = %entry

• %eh_ptr = call i8 @​llvm.eh.exception() ; <i8> [#uses=1]
• %eh_ptr = call i8 @​llvm.eh.exception() ; <i8> [#uses=5]
  store i8* %eh_ptr, i8** %eh_exception
• %eh_ptr3 = load i8* %eh_exception ; <i8> [#uses=1]
• %eh_select4 = call i64 (i8, i8, ...) @​llvm.eh.selector.i64(i8 %eh_ptr3, i8 bitcast (i32 (...) @​__gxx_personality_v0 to i8), i8 null) ; [#uses=1]
• %eh_select4 = call i64 (i8, i8, ...) @​llvm.eh.selector.i64(i8 %eh_ptr, i8 bitcast (i32 (...) @​__gxx_personality_v0 to i8), i8 null) ; [#uses=3] store i64 %eh_select4, i64* %eh_selector
• br label %ppad
• store i64 %eh_select4, i64* %save_filt.1054, align 8
• store i8* %eh_ptr, i8** %save_eptr.1053, align 8
• invoke void @​_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev(%"struct.std::basic_stringstream<char,std::char_traits,std::allocator >"* %ss)
• to label %invcont1 unwind label %lpad5

-lpad5: ; preds = %bb

• %eh_ptr6 = call i8 @​llvm.eh.exception() ; <i8> [#uses=1] +lpad5: ; preds = %lpad
• %eh_ptr6 = call i8 @​llvm.eh.exception() ; <i8> [#uses=2] store i8* %eh_ptr6, i8** %eh_exception
• %eh_ptr7 = load i8* %eh_exception ; <i8> [#uses=1]
• %eh_select8 = call i64 (i8, i8, ...) @​llvm.eh.selector.i64(i8 %eh_ptr7, i8 bitcast (i32 (...) @​__gxx_personality_v0 to i8*), i32 1) ; [#uses=1]
• %eh_select8 = call i64 (i8, i8, ...) @​llvm.eh.selector.i64(i8 %eh_ptr6, i8 bitcast (i32 (...) @​__gxx_personality_v0 to i8), i32 1) ; [#uses=1] store i64 %eh_select8, i64 %eh_selector
• br label %ppad9

• -ppad: ; preds = %lpad

• br label %bb

• -ppad9: ; preds = %lpad5

• br label %bb2

• -Unwind: ; preds = %invcont1

• %eh_ptr10 = load i8* %eh_exception ; <i8> [#uses=1]
• call void @​_Unwind_Resume(i8* %eh_ptr10)
• call void @​_ZSt9terminatev() noreturn nounwind unreachable }

To reproduce run: opt -gvn bugpoint-tooptimize.bc, and look at the output (see diff above), if you run -dse too, then the EH stuff is completely broken.

I have debugged this using bugpoint like so: bugpoint -Xlinker="-Wl,/tmp/api.o,-lstdc++" -safe-run-custom -run-custom -exec-command ./test2.sh -simplifycfg -domtree -domfrontier -mem2reg -instcombine -simplifycfg -simplify-libcalls -instcombine -jump-threading -simplifycfg -domtree -domfrontier -scalarrepl -instcombine -break-crit-edges -condprop -tailcallelim -simplifycfg -reassociate -domtree -loops -loopsimplify -domfrontier -lcssa -loop-rotate -licm -lcssa -loop-unswitch -instcombine -scalar-evolution -lcssa -iv-users -indvars -loop-deletion -instcombine -memdep -gvn -memdep -memcpyopt -sccp -instcombine -break-crit-edges -condprop -domtree -memdep -dse -adce -simplifycfg -preverify -domtree -verify x.bc

[edwintorok]

Ok, the problem is that some files #define NDEBUG, others don't, and if you link a file compiled with NDEBUG that includes boost/date_time/posix_time/posix_time.hpp, with one that includes it w/o defining NDEBUG then bad things happen.

With gcc at -O1 everything is fine, and the result is valgrind clean, however even with gcc at -O0 it segfaults if one files defines it, and the other one doesn't.

Now llvm-gcc at -O1 optimized things differently and preserved the bad behaviour.

Doesn't look like a bug in LLVM, sorry for the noise.

[llvmbot]

Is the problem that it calls terminate?

[lattner]

I don't see an invalid transformation here. It seems likely that gvn is exposing a codegen bug.

[edwintorok]

To see the bad output from the program: $ llvm-g++ api.i -o api.o $ llvm-g++ x.i -O1 -o x.o $ llvm-g++ x.o api.o $ ./a.out

^fails vs. works: $ llvm-g++ api.i -o api.o $ llvm-g++ x.i -O0 -o x.o $ llvm-g++ x.o api.o $ ./a.out