[LLVMdev] Darwin vs exceptions

Duncan Sands baldrick at free.fr
Sun Dec 9 10:26:41 PST 2007

Hi Dale,

> OK, playing around with the testsuite it appears there's a bug in  
> llvm's inliner with EH, which is probably what's causing the effect  
> you're talking about.  Suppose we have
> #include <cstdio>
> class A {
> public:
>    A() {}
>    ~A() {}
> };
> void f() {
>    A a;
>    throw 5.0;
> }
> main() {
>    try {
>      f();
>     } catch(...) { printf("caught\n"); }
> }
> The IR for f correctly has the throw call reaching the landing pad,  
> which cleans up 'a' and then calls Unwind_Resume.  Inlining g into f  
> naively copies this structure which is wrong; we do not want to call  
> Unwind_Resume in this case because there is a real handler in the  
> same function.  See the code produced by gcc -O3.  I think what you  
> did is make this incorrect Unwind_Resume work (on your OS), but  
> that's not the right way to fix this.

I don't see why you consider it a bug.  It seems perfectly correct
to me, only suboptimal.  For those watching, the issue is that after
inlining by LLVM you get this

        invoke i32 (...)* @_Unwind_Resume( i8* %eh_ptr.i )
                        to label %UnifiedUnreachableBlock unwind label %lpad            ; <i32>:0 [#uses=0]

where this invoke is rather silly.  But I don't see that it is wrong.
By the way, the gcc inliner knows about _Unwind_Resume so you don't see
this if gcc did the inlining.



More information about the llvm-dev mailing list