-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Landing pad wrongly removed #1794
Comments
I think I know what's going on, though I'm not sure. The landing pad MBB is |
I will look. |
Thanks. I now think the origin of the problem is much earlier: |
Sorry not to have gotten to this sooner; I've been sick. |
But the first thing you said is also true, and the easiest way to fix it is not to optimize away a forwarder |
Hi Dale, I hope you're feeling better!
It looks to me that this problem comes from instruction lowering. invoke_bb: The lowering of invoke marks %unwind.crit as a landing pad.
Yes, I agree. My understanding is that a MBB B is marked as Given this, if B is a landing pad and you rewrite any predecessor I think the following invariant should hold: if a MBB contains This invariant doesn't hold right now, see the first part of this comment, Suppose this invariant holds. Recall that the unwinder will It seems to me that this means that there is nothing to worry OK, so now let me comment on this part of your patch (thanks for // If this block is empty, make everyone use its fall-through, not the block
I think you could instead just copy the landing pad flag to the new By the way, for the sake of uniformity I reckon it would be wise |
You may be correct that it's safe just to transfer the landing-pad bit; the change I put in is conservatively |
mentioned in issue llvm/llvm-bugzilla-archive#1444 |
Extended Description
In the attached testcase, consider the following call to __gnat_rcheck_12:
invoke void @__gnat_rcheck_12( i8* getelementptr ([13 x i8]* @.str, i32 0, i32
0), i32 103 )
to label %UnifiedUnreachableBlock unwind label %unwind869
[This is the only call taking 103 as last parameter]. After codegen with
llc -enable-eh, this invoke has no entry in the eh table and the unwind
block %unwind869 seems to have been deleted. This is unfortunate because
when run this call is executed and raises an exception which is not caught...
The text was updated successfully, but these errors were encountered: