<div dir="ltr">Yes, it's good to merge.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 9:42 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David, is this OK for 3.8? The PR is marked as a potential release blocker.<br>
<br>
On Tue, Jan 19, 2016 at 6:15 PM, Joseph Tremoulet via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Author: josepht<br>
> Date: Tue Jan 19 20:15:15 2016<br>
> New Revision: 258273<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=258273&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=258273&view=rev</a><br>
> Log:<br>
> [Inliner/WinEH] Honor implicit nounwinds<br>
><br>
> Summary:<br>
> Funclet EH tables require that a given funclet have only one unwind<br>
> destination for exceptional exits.  The verifier will therefore reject<br>
> e.g. two cleanuprets with different unwind dests for the same cleanup, or<br>
> two invokes exiting the same funclet but to different unwind dests.<br>
> Because catchswitch has no 'nounwind' variant, and because IR producers<br>
> are not *required* to annotate calls which will not unwind as 'nounwind',<br>
> it is legal to nest a call or an "unwind to caller" catchswitch within a<br>
> funclet pad that has an unwind destination other than caller; it is<br>
> undefined behavior for such a call or catchswitch to unwind.<br>
><br>
> Normally when inlining an invoke, calls in the inlined sequence are<br>
> rewritten to invokes that unwind to the callsite invoke's unwind<br>
> destination, and "unwind to caller" catchswitches in the inlined sequence<br>
> are rewritten to unwind to the callsite invoke's unwind destination.<br>
> However, if such a call or "unwind to caller" catchswitch is located in a<br>
> callee funclet that has another exceptional exit with an unwind<br>
> destination within the callee, applying the normal transformation would<br>
> give that callee funclet multiple unwind destinations for its exceptional<br>
> exits.  There would be no way for EH table generation to determine which<br>
> is the "true" exit, and the verifier would reject the function<br>
> accordingly.<br>
><br>
> Add logic to the inliner to detect these cases and leave such calls and<br>
> "unwind to caller" catchswitches as calls and "unwind to caller"<br>
> catchswitches in the inlined sequence.<br>
><br>
> This fixes PR26147.<br>
><br>
><br>
> Reviewers: rnk, andrew.w.kaylor, majnemer<br>
><br>
> Subscribers: alexcrichton, llvm-commits<br>
><br>
> Differential Revision: <a href="http://reviews.llvm.org/D16319" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16319</a><br>
</blockquote></div><br></div>