[llvm-bugs] [Bug 42064] New: Optimized 128-bit atomic compare-and-swap can generate incorrect code on msvc target
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed May 29 12:42:34 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=42064
Bug ID: 42064
Summary: Optimized 128-bit atomic compare-and-swap can generate
incorrect code on msvc target
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangbugs at nondot.org
Reporter: cerickson at curedev.com
CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
richard-llvm at metafoo.co.uk
Created attachment 22047
--> https://bugs.llvm.org/attachment.cgi?id=22047&action=edit
Example source code
When compiling the attached source with:
clang --target=x86_64-pc-windows-msvc -march=sandybridge -O2
it appears that the generated code tries to use rbx as both an input for
cmpxchg16b and as a stack pointer:
mov rbx, rsp
...
movabs rax, 1393743441367457520
mov rdx, rax
mov rcx, rax
mov rbx, rax
lock cmpxchg16b xmmword ptr [r8]
vxorps xmm0, xmm0, xmm0
vmovaps xmmword ptr [rbx + 128], xmm0 // rbx is garbage at this point
The example C++ code is a bit silly because it is as reduced as I could get it
and still have the problem occur. The same issue occurs whether using
_InterlockedCompareExchange128() or __sync_val_compare_and_swap().
For convenience, here is the example on godbolt: https://godbolt.org/z/C64_VH
I ran into this issue in clang 7.0.0 but it seems to still be there in trunk
(according to godbolt).
--
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/20190529/a02df847/attachment.html>
More information about the llvm-bugs
mailing list