[LLVMdev] Assertion failure in llc when using exception handling

[Shivram Khandeparker]

Forgot to reply all.

Duncan suggested that I put the selector call before the store but that
didn't help. I get the same assertion failure.

On Thu, Jun 10, 2010 at 2:50 PM, Shivram Khandeparker <shivramk at gmail.com>wrote:

> HI Duncan,
>
> On Thu, Jun 10, 2010 at 1:58 PM, Duncan Sands <baldrick at free.fr> wrote:
>
>> an unfortunate weakness of the code generators is that they require calls
>> to
>> eh.selector to be in a landing pad (landing pad = where an invoke unwinds
>> to).  They can also handle some simple cases when the selector call is
>> outside
>> the landing pad.  In practice, as long as the original call to eh.selector
>> that
>> you generate is in a landing pad, and at the start of the landing pad
>> (just
>> after the eh.exception call and any phi nodes) it is intended that the
>> current
>> logic is good enough to handle any situations caused by optimization.  Was
>> the
>> original call at the start of a landing pad?
>>
>
> I am aware of this. All of the landing pads in my original code look like
> the following
>
> lpad:                                             ; preds = %return7
>   %46 = call i8* @llvm.eh.exception()             ; <i8*> [#uses=2]
>   store i8* %46, i8** %22
>   %47 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %46, i8* bitcast
> (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0]
>   br label %destructor
>
> eh.selector always follows the eh.exception call and the store.
>
>
>> By the way, there are various ways of fixing this codegen problem.  But
>> since
>> there is a plan to redesign exception handling in LLVM, it seems pointless
>> to
>> spend much time on it.
>>
>
> It would be great if you could suggest a workaround till exception handling
> in LLVM gets redesigned. I would really like to get this working as soon as
> possible.
>
> Regards,
> Shivram
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100610/f922f553/attachment.html>