LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 32020 - [MIPS] unoptimized __atomic_compare_exchange hangs on Octeon
Summary: [MIPS] unoptimized __atomic_compare_exchange hangs on Octeon
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: MIPS (show other bugs)
Version: 4.0
Hardware: PC Linux
: P normal
Assignee: Simon Dardis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-20 04:05 PST by James Cowgill
Modified: 2018-10-12 04:05 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description James Cowgill 2017-02-20 04:05:12 PST 
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
Comment 1 Simon Dardis 2017-02-20 04:29:06 PST 
Looking into this.
Comment 2 Simon Dardis 2017-02-21 06:09:43 PST 
This is a occurrence of PR/25526 but for MIPS. I'm currently trialling a fix.
Comment 3 Simon Dardis 2017-02-27 04:51:01 PST 
Should be resolved by r296134.
Comment 4 James Cowgill 2017-03-01 04:03:21 PST 
Thanks! I've tested the fix and it works now.

Is it possible for this to be fixed in either 4.0 or 4.0.1 as well?
Comment 5 Simon Dardis 2017-03-01 07:39:30 PST 
I've requested it be merged today for 4.0. If not, I'll try and get it in for the next point release of 4.0.
Comment 6 Simon Dardis 2017-03-09 05:23:33 PST 
The fix posted has problems, reopening this while I work up another solution.
Comment 7 Simon Dardis 2017-03-09 05:24:10 PST 
The fix posted has problems, reopening this while I work up another solution.
Comment 8 James Cowgill 2017-08-16 06:45:18 PDT 
Has there been any progress on this bug?
Comment 9 Simon Dardis 2017-08-16 06:55:51 PDT 
I have a fix, but I want to perform more testing before recommitting it. My last attempt fudged handed allocated register, resulting in segfaults everywhere.
Comment 10 Simon Atanasyan 2018-09-28 02:55:43 PDT 
(In reply to Simon Dardis from comment #9)
> I have a fix, but I want to perform more testing before recommitting it. My
> last attempt fudged handed allocated register, resulting in segfaults
> everywhere.

SimonD, do you have the fix (maybe incomplete) mentioned in your comment? Could you please share it?
Comment 11 Lidija Besker 2018-10-11 06:49:01 PDT 
I had a look at this bug and it was resolved in r336328. I recommend closing it.
Comment 12 Simon Atanasyan 2018-10-12 04:05:21 PDT 
Fixed at https://reviews.llvm.org/rL336328.