[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.
Ciao,
Duncan.
More information about the llvm-dev
mailing list