[llvm-bugs] [Bug 32020] New: [MIPS] unoptimized __atomic_compare_exchange hangs on Octeon
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Feb 20 04:05:12 PST 2017
https://bugs.llvm.org/show_bug.cgi?id=32020
Bug ID: 32020
Summary: [MIPS] unoptimized __atomic_compare_exchange hangs on
Octeon
Product: libraries
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: MIPS
Assignee: unassignedbugs at nondot.org
Reporter: james410 at cowgill.org.uk
CC: llvm-bugs at lists.llvm.org
Hi,
Testcase:
> int main(void)
> {
> volatile int obj = 1;
> int x = obj;
>
> __atomic_compare_exchange_n(&obj, &x, 0, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
> }
Compiling with:
clang-4.0 -O0 test.c -otes
Running "test" hangs on Cavium Octeon machines. The bug does not occur if -O1
is used.
The generated assembly contains this loop:
> .LBB0_1:
> ld $1, 16($fp)
> ll $2, 0($1)
> lw $3, 32($fp)
> sw $2, 12($fp)
> bne $2, $3, .LBB0_3
> nop
> lw $1, 28($fp)
> ld $2, 16($fp)
> sc $1, 0($2)
> beqz $1, .LBB0_1
> nop
However the Octeon processor manual states that _any_ store will cause a
subsequent sc instruction to fail and therefore this above loop will never
complete on Octeon.
Thanks,
James
--
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/20170220/685a20b2/attachment.html>
More information about the llvm-bugs
mailing list