diff options
| author | Mazdak Farrokhzad <twingoow@gmail.com> | 2019-11-20 12:58:35 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-11-20 12:58:35 +0100 |
| commit | fff8ae1aa80448c19b5b805355e55d95c6c86fb2 (patch) | |
| tree | f5abb21bd17bbc16b221de14557cd07dde1d811b /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 499760450305f6d2f565549dbd9b2d3c95cd7774 (diff) | |
| parent | ca42c25598b2d4f1842dc18af6992daea0b0fca9 (diff) | |
| download | rust-fff8ae1aa80448c19b5b805355e55d95c6c86fb2.tar.gz rust-fff8ae1aa80448c19b5b805355e55d95c6c86fb2.zip | |
Rollup merge of #66548 - lenary:riscv/disable-atomics-non-a, r=alexcrichton
[RISCV] Disable Atomics on all Non-A RISC-V targets In a `TargetOptions` configuration, `max_atomic_width: None` causes `max_atomic_width()` to return `Some(target_pointer_width)`. So, contrary to assumptions, `max_atomic_width: None` means you do have atomic support! RISC-V's rv32i and rv32imc do not have architectural support for atomic memory accesses of any size, because they do not include the `A` architecture extension. This means the values in the target definition should be `Some(0)`. This bug has been observed via a build failure with oreboot/oreboot#191, where LLVM was still generating libcalls for atomic operations. According to rust-lang/compiler-builtins, "Rust only exposes atomic types on platforms that support them, and therefore does not need to fall back to software implementations." - so this PR tries to bring rustc inline with this decision. This commit also removes the outdated bug link, which references a now irrelevant GCC bug. I will likely also have to revisit the `min_atomic_width` of all the RISC-V targets so they are correct and match what the hardware is capable of (which is more restricted than one might imagine). r? @alexcrichton
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
