This adds support for preserving the correct control flow representation in the case where a nested landing pad returns to a block in the parent function. This can happen, for instance, in a case where the landing pad in question originally enclosed the handler in which it is nested in the user's source code but can only be reached from the enclosed landing pad. The following code is an example:
void test1() { try { try { throw 1; } catch(...) { throw; } } catch (...) { } }
In such a case, we must represent the block to which the "nested" landing pad returns as a possible target of the landing pad in which it is enclosed in order to prevent the target block from being eliminated as dead code.
This patch only handles to case described at the WinEHPrepare level. There are still problem executing a program which includes the case above, but I can reproduce the same failures without the scenario that this patch is meant to address.
wrap