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: unassignedclangb...@nondot.org
Reporter: cerick...@curedev.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
