Repository: rust
Issue: AtomicUsize `fetch_add` hangs indefinetly on aarch64 (ThunderX)
Labels: C-bug,O-AArch64

I tried this code:

```rust
use std::sync::atomic::{AtomicUsize, Ordering};

static ID: AtomicUsize = AtomicUsize::new(0);

fn main() {
  ID.fetch_add(1, Ordering::Relaxed);
}
```

I expected to see this happen: The program to end

Instead, this happened: The program hung forever with a core at 100% load



### Meta

`rustc --version --verbose`:
```
rustc 1.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: aarch64-unknown-linux-gnu
release: 1.52.1
LLVM version: 12.0.0
```

and

```
rustc 1.54.0-nightly (dbe459ded 2021-06-02)
binary: rustc
commit-hash: dbe459dedd33470f2cb28101157de316caaffa66
commit-date: 2021-06-02
host: aarch64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1
```

This is running in a Cavium ThunderX ARM cpu:

```
Architecture:                    aarch64
CPU op-mode(s):                  64-bit
Byte Order:                      Little Endian
CPU(s):                          48
On-line CPU(s) list:             0-47
Thread(s) per core:              1
Core(s) per socket:              48
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       Cavium
Model:                           1
Model name:                      ThunderX 88XX
Stepping:                        0x1
BogoMIPS:                        200.00
NUMA node0 CPU(s):               0-47
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
```


<details><summary>Backtrace</summary>

Since the program hangs indefinitely no crash backtrace exists, but running it in `rust-lldb` gives the following backtrace:

<p>

```
* thread #1, name = 'atomic-add', stop reason = signal SIGSTOP
    frame #0: 0x0000aaaaaaaafa6c atomic-add`core::sync::atomic::atomic_add::h05d87558f9bdb971(dst=0x0000aaaaaaaf2060, val=1, order=Relaxed) at atomic.rs:2382:24
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, name = 'atomic-add', stop reason = signal SIGSTOP
  * frame #0: 0x0000aaaaaaaafa6c atomic-add`core::sync::atomic::atomic_add::h05d87558f9bdb971(dst=0x0000aaaaaaaf2060, val=1, order=Relaxed) at atomic.rs:2382:24
    frame #1: 0x0000aaaaaaaafac8 atomic-add`core::sync::atomic::AtomicUsize::fetch_add::h38e434dfb7de1826(self=0x0000aaaaaaaf2060, val=1, order=Relaxed) at atomic.rs:1735:26
    frame #2: 0x0000aaaaaaaaf834 atomic-add`atomic_add::main::h89962fd9723e6a47 at main.rs:6:3
    frame #3: 0x0000aaaaaaaaf8a8 atomic-add`core::ops::function::FnOnce::call_once::h274b37448b4bd3f4((null)=(atomic-add`atomic_add::main::h89962fd9723e6a47 at main.rs:5), (null)=<unavailable>) at function.rs:227:5
    frame #4: 0x0000aaaaaaaafb3c atomic-add`std::sys_common::backtrace::__rust_begin_short_backtrace::h96ff16390dff76e9(f=(atomic-add`atomic_add::main::h89962fd9723e6a47 at main.rs:5)) at backtrace.rs:125:18
    frame #5: 0x0000aaaaaaaaf96c atomic-add`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h7c395efe9cdd05c0 at rt.rs:66:18
    frame #6: 0x0000aaaaaaac2908 atomic-add`std::rt::lang_start_internal::hac4960093806604a [inlined] core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::h4d3b62c1d18fb3b6 at function.rs:259:13
    frame #7: 0x0000aaaaaaac28fc atomic-add`std::rt::lang_start_internal::hac4960093806604a [inlined] std::panicking::try::do_call::hc71f0a2fd1d3493d at panicking.rs:379
    frame #8: 0x0000aaaaaaac28fc atomic-add`std::rt::lang_start_internal::hac4960093806604a [inlined] std::panicking::try::h80c19bdf246b0ee1 at panicking.rs:343
    frame #9: 0x0000aaaaaaac28fc atomic-add`std::rt::lang_start_internal::hac4960093806604a [inlined] std::panic::catch_unwind::h287ea33e6344c7c1 at panic.rs:431
    frame #10: 0x0000aaaaaaac28fc atomic-add`std::rt::lang_start_internal::hac4960093806604a at rt.rs:51
    frame #11: 0x0000aaaaaaaaf944 atomic-add`std::rt::lang_start::h09be16629ca574c0(main=(atomic-add`atomic_add::main::h89962fd9723e6a47 at main.rs:5), argc=1, argv=0x0000fffffffff268) at rt.rs:65:5
    frame #12: 0x0000aaaaaaaaf868 atomic-add`main + 40
    frame #13: 0x0000fffff7e14090 libc.so.6`__libc_start_main + 232
    frame #14: 0x0000aaaaaaaaf718 atomic-add`_start + 52

```

</p>
</details>

credit to @cuviper for helping to track this down ( https://github.com/cuviper/autocfg/issues/36 )