[llvm-bugs] [Bug 24773] New: WinEHPrepare fails on __try / __finally inside __try / __except

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24773

            Bug ID: 24773
           Summary: WinEHPrepare fails on __try / __finally inside __try /
                    __except
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 14864
  --> https://llvm.org/bugs/attachment.cgi?id=14864&action=edit
IR

Two things go wrong starting from this C++ test case (IR attached):

extern "C" int printf(const char *, ...);
int do_div(int a, int b) { return a / b; }
int main() {
  int r = 0;
  __try {
    __try {
      r = do_div(1, 0);
    } __finally {
      printf("finally\n");
    }
  } __except (1) {
    printf("caught\n");
  }
  printf("1 / 0: %d\n", r);
  return 0;
}

First, having a single-BB catch funclet seems to confuse WinEHPrepare. It ends
up cloning the subsequent blocks and transforms the "implausible" ret as
unreachable.

Second, if I run -O1 on the IR, demotion fails like this:
$ opt -O1 -winehprepare t.ll -S -o -
Instruction does not dominate all uses!
  %call.wineh.reload.wineh.reload = load i32, i32*
%call.wineh.reload.wineh.spillslot
  %call4 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([11 x i8],
[11 x i8]* @"\01??_C at _0L@HIGBIMNM at 1?5?1?50?3?5?$CFd?6?$AA@", i32 0, i32 0), i32
%call.wineh.reload.wineh.reload)
LLVM ERROR: Broken function found, compilation aborted!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150910/064eadae/attachment-0001.html>