[llvm-bugs] [Bug 32020] New: [MIPS] unoptimized __atomic_compare_exchange hangs on Octeon

[via llvm-bugs]

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>