about summary refs log tree commit diff
path: root/src/libstd/sys/unix/stack_overflow.rs
diff options
context:
space:
mode:
authorMazdak Farrokhzad <twingoow@gmail.com>2019-11-20 12:58:35 +0100
committerGitHub <noreply@github.com>2019-11-20 12:58:35 +0100
commitfff8ae1aa80448c19b5b805355e55d95c6c86fb2 (patch)
treef5abb21bd17bbc16b221de14557cd07dde1d811b /src/libstd/sys/unix/stack_overflow.rs
parent499760450305f6d2f565549dbd9b2d3c95cd7774 (diff)
parentca42c25598b2d4f1842dc18af6992daea0b0fca9 (diff)
downloadrust-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