In the testcase there are two calls to @__cxa_throw, one of which is an invoke the other a normal call. [Only the invoke one should be called when the program is run]. After codegen llc -enable-eh -asm-verbose e.bc there is only one call to @__cxa_throw but it is the wrong one! First of all, from the assembler comment (#finally) you can see that it is the normal call version that got put in (the other is in finally.i): .LBB2_1: #finally movl $_ZTI1A, 4(%esp) movl $_ZN1AD1Ev, 8(%esp) movl %esi, (%esp) call __cxa_throw .LBB2_2: #unwind Secondly, in the exception handling table there is no landing pad for this code range, there is only .long .Llabel4-.Leh_func_begin2 # Region start .long .Llabel5-.Llabel4 # Region length .long 0x0 # Landing pad .uleb128 0 # Action which does not cover this. My guess is that codegen cleverly saw that it could collapse the two calls to @__cxa_throw into one call, thinking that they were equivalent, without noticing that they differed in that one was an invoke.
Created attachment 865 [details] testcase .ll
Created attachment 866 [details] original .cpp
Is this a new regression?
> Is this a new regression? I don't know.
Tail merging, mine.
Wrong again, this fails identically with tail merging turned off. Nor is it branch folding. I do not understand how this works well enough to figure it out.
Dale, this is EH issue. <aKor> The problem is: <aKor> 1. Call is known to throw <aKor> 2. But, it's outside any EH scope <aKor> we're not creating invoke in this case <aKor> this is right <baldrick> inside f() it is; however the call to f() is an invoke <aKor> yes <baldrick> I mean, inside f() it is outside any eh scope <baldrick> doesn't this just indicate that stack unwinding is not working properly? <aKor> yes, in some sence: <aKor> if there won't be frame with personality function specified, it will unwind upper by default <aKor> by when we have personality function, we should mark every call as "can throw" and emit null LPs <aKor> (this is how gcc does) <aKor> so, this is some sort of "invalid EH information emitted" :)
Fixed with: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/049953.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/049954.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/049955.html