[llvm-bugs] [Bug 36103] New: LLVM overwrites spilled xmm registers in crash handler

[via llvm-bugs]

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

            Bug ID: 36103
           Summary: LLVM overwrites spilled xmm registers in crash 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 19754
  --> https://bugs.llvm.org/attachment.cgi?id=19754&action=edit
Reduced test case

See dbl3.ll (in the attached zip). If I assemble this with

% opt -mem2reg -mtriple x86_64-windows-msvc -S -o - dbl3.ll | \
    llc -filetype=asm -o - -

the function prologue has

"?z@@YANXZ":                            # @"\01?z@@YANXZ"
.Lfunc_begin0:
.seh_proc "?z@@YANXZ"
        .seh_handler __CxxFrameHandler3, @unwind, @except
# %bb.0:                                # %entry
        pushq   %rbp
        .seh_pushreg 5
        subq    $64, %rsp
        .seh_stackalloc 64
        leaq    64(%rsp), %rbp
        .seh_setframe 5, 64
        movaps  %xmm6, -16(%rbp)        # 16-byte Spill
        .seh_savexmm 6, 48
        .seh_endprologue

and the catch handler prologue has

"?catch$4@?0??z@@YANXZ at 4HA":
.seh_proc "?catch$4@?0??z@@YANXZ at 4HA"
        .seh_handler __CxxFrameHandler3, @unwind, @except
.LBB0_4:                                # %catch
        movq    %rdx, 16(%rsp)
        pushq   %rbp
        .seh_pushreg 5
        subq    $32, %rsp
        .seh_stackalloc 32
        leaq    64(%rdx), %rbp
        movapd  %xmm6, -16(%rbp)        # 16-byte Spill
        .seh_savexmm 6, 48
        .seh_endprologue

Note that the catch handler saves xmm6 to the stack to the exact same slot the
function prologue saved it to. In other words, when the catch handler is
entered, the *current* value of xmm6, which has already been overwritten inside
the function, is saved to the stack, overwriting the original value that was
saved in the function prologue. The function epilogue will therefore restore an
incorrect value to xmm6.

dbl.cpp, dbl2.cpp, and dbl3.cpp in the attached zip represent a complete
example demonstrating the problem. If you run

% clang-cl /O1 /EHsc dbl.cpp dbl2.cpp dbl3.cpp

and then execute dbl.exe, the exit code should be 1 rather than 0, because of
xmm6 getting trashed. Compiling with cl and running the compiled program yields
an exit code of 0, as expected.

I've reproduced this with clang 5, clang 6, and trunk, so it seems like it goes
a long way back.

-- 
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/20180126/513b3774/attachment.html>