David Majnemer 1fad37bd8d [WinEH] Don't miscompile cleanups which conditionally unwind to caller ... A cleanup can have paths which unwind or end up in unreachable. If there is an unreachable path *and* a path which unwinds to caller, we would mistakenly inject an unwind path to a catchswitch on the unreachable path. This results in a verifier assertion firing because the cleanup unwinds to two different places: to the caller and to the catchswitch. This occured because we used getCleanupRetUnwindDest to determine if the cleanuppad had no cleanuprets. This is incorrect, getCleanupRetUnwindDest returns null for cleanuprets which unwind to caller. llvm-svn: 258651		2016-01-23 23:54:33 +00:00
..
lit.local.cfg
wineh-cleanuppad-nounwind.ll	[WinEH] Don't miscompile cleanups which conditionally unwind to caller	2016-01-23 23:54:33 +00:00
wineh-cloning.ll	[WinEH] Let cleanups post-dominated by unreachable get executed	2016-01-22 23:20:43 +00:00
wineh-demotion.ll	[WinEH] Let cleanups post-dominated by unreachable get executed	2016-01-22 23:20:43 +00:00
wineh-intrinsics-invalid.ll	[WinEH] Add llvm.eh.exceptionpointer intrinsic	2015-09-03 09:15:32 +00:00
wineh-intrinsics.ll	[IR] Reformulate LLVM's EH funclet IR	2015-12-12 05:38:55 +00:00
wineh-no-demotion.ll	[WinEH] Let cleanups post-dominated by unreachable get executed	2016-01-22 23:20:43 +00:00
wineh-statenumbering-cleanups.ll	[IR] Reformulate LLVM's EH funclet IR	2015-12-12 05:38:55 +00:00
wineh-statenumbering.ll	[WinEH] Verify consistent funclet unwind exits	2016-01-10 04:30:02 +00:00