[llvm-bugs] [Bug 36247] New: [WinEH] Inline assembly corrupts catch handler

[via llvm-bugs]

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

            Bug ID: 36247
           Summary: [WinEH] Inline assembly corrupts catch handler
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: smeenai at fb.com
                CC: compnerd at compnerd.org, david.majnemer at gmail.com,
                    llvm-bugs at lists.llvm.org, rnk at google.com

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

% cat exc.cpp
void f();
int main() {
    try {
        f();
    } catch (int) {
        __asm__ ("nop");
        return 0;
    }
    return 1;
}

% clang -target i686-windows-msvc -S -o - exc.cpp
...
"?catch$1@?0?main at 4HA":
LBB0_1:                                 # %catch
        pushl   %ebp
        addl    $12, %ebp
        movl    %esp, -28(%ebp)
Lfunc_end0:
        .section        .xdata,"dr"
        .p2align        2
L__ehtable$main:
        .long   429065506               # MagicNumber
...

Note that the EH table is emitted in the middle of the catch handler's code
(right after its prologue), which is obviously bogus. Slightly cleaned up IR
generated from the C++ source above is attached for convenience. Removing the
`call void asm` from the IR makes llc generate sane assembly for the catch
handler.

The same occurs for x86-64, but MS doesn't officially support inline assembly
for x86-64, so I presume we don't care too much. To be perfectly honest, I
don't care very much about the x86 case either, since I have a trivial local
workaround; I'm just reporting it for completeness.

-- 
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/20180206/1aa9acb1/attachment.html>