Repository navigation
Tracking issue for integer_atomics (AtomicU128/AtomicI128) #99069
Description
Tracking rust-lang/rfcs#1543.
- std::sync::atomic::AtomicI128
- std::sync::atomic::AtomicU128
Seems related to #56071. See also #57425 which stabilized other atomic integer widths.
Probably blocked by various LLVM issues:
Activity
Update integer_atomics tracking issue
Rollup merge of rust-lang#99070 - tamird:update-tracking-issue, r=Ral…
Rollup merge of rust-lang#99070 - tamird:update-tracking-issue, r=Ral…
RalfJung commentedon Jul 9, 2022
It'd be good to list the APIs that are covered by this tracking issue, and copy any open questions that have been noted in the RFC of the previous tracking issue.
Update integer_atomics tracking issue
Rollup merge of rust-lang#99070 - tamird:update-tracking-issue, r=Ral…
kadiwa4 commentedon Jul 28, 2022
The unstable
ATOMIC_*_INITconstants can be removed, right? Or should they be stabilized for consistency with the stableATOMIC_*_INITconstants? (All of them are deprecated.)eric-seppanen commentedon Jan 17, 2023
The standard library docs for
AtomicU128, etc. still point to #32976 instead of here.kadiwa4 commentedon Jan 17, 2023
What do you mean?
(rust 1.66.1)
Interestingly, in the online documentation the types don't show up at all, whereas they do show up in my local copy (
rust-docsfrom rustup).eric-seppanen commentedon Jan 17, 2023
Apologies, I must have accidentally followed a link to somebody else's stale docs.
gitmalong commentedon Mar 8, 2023
the trait bound
std::sync::atomic::AtomicU128: mymod::_::_serde::Deserialize<'_>is not satisfied. Where to fill an issue for that?37 remaining items
taiki-e commentedon Apr 2, 2026
@RalfJung
This is a bug in the LLVM AArch64 backend, and not a limitation of the AArch64 atomic ABI itself.
The lowering adopted in GCC and C/C++ Atomics Application Binary Interface Standard for the Arm® 64-bit Architecture is compatible regardless of the target features.
LLVM's current lowering is the one that was also used in GCC in the past but was replaced with the new one because this issue was found.
Whether FEAT_LSE2 (
lse2target feature) is available.tgross35 commentedon Apr 2, 2026
On Linux at least it should be using lse2 on most newer hardware via runtime feature detection. This was expanded to other platforms in #144938 but unfortunately needed to be reverted (rust-lang/compiler-builtins#1063 will fix the issue).
taiki-e commentedon Apr 2, 2026
@tgross35 outline-atomics is about FEAT_LSE, not FEAT_LSE2.
folkertdev commentedon Jul 9, 2026
Updating here that the aarch64 fix got merged and will be in LLVM 23
The x86 fix has not been merged though
cmpxchg16bfor 128-bit atomics on x86_64 llvm/llvm-project#187503cc @usamoi maybe you can give that another push
RalfJung commentedon Jul 9, 2026
Are x86-64 and aarch64 the only targets where 128bit atomics are supported, or are there other targets we have to worry about?
bjorn3 commentedon Jul 9, 2026
Cranelift doesn't yet support 128bit atomics. I've had to patch them out when building the standard library for arm64 using cg_clif for this reason: https://github.com/rust-lang/rustc_codegen_cranelift/blob/5bbb9e4f6618aa7c32bde230875fa36608e60bdf/patches/0027-stdlib-128bit-atomic-operations.patch, https://github.com/rust-lang/rustc_codegen_cranelift/blob/5bbb9e4f6618aa7c32bde230875fa36608e60bdf/patches/0027-sysroot_tests-128bit-atomic-operations.patch, https://github.com/rust-lang/rustc_codegen_cranelift/blob/5bbb9e4f6618aa7c32bde230875fa36608e60bdf/src/intrinsics/mod.rs#L862-L877
tgross35 commentedon Jul 9, 2026
https://github.com/taiki-e/portable-atomic/blob/c8a25378a8dd54ba2450d38f6fe5c5e1c9558ca1/src/imp/atomic128/README.md has a list. It looks like at least rv64, ppc64, and s390x have implementations, all requiring non-baseline target features.
If we have different confidence levels for different arches, maybe it would be fine to stabilize by arch? That way we can at least provide aarch64 and possibly x86 at the next LLVM bump, and add the others after they've gotten a bit more proven out.
Couldn't clif just unset
target_has_atomic_load_store = "128"?bjorn3 commentedon Jul 9, 2026
No, codegen backends can't change the target spec.
RalfJung commentedon Jul 9, 2026
Codegen backends can already change
cfg(target_features), sounds like we should wire something up so they can also adjust thecfgs for atomics.RalfJung commentedon Jul 9, 2026
The bigger problem is that we currently support mixing crates built with different codegen backends. The distributed std is built with LLVM so the 128bit atomic types will be available downstream even if downstream uses cranelift.
OTOH I don't think we should block 128bit atomics on cranelift support. I'm fine with waiting a few months for some work-in-progress support on the cranelift side to complete, but blocking indefinitely while our default backend has support would not be great.
taiki-e commentedon Jul 17, 2026
It is also available in the baseline of s390x and little-endian powerpc64; rustc enables 128-bit atomics for the former (#130558). It is not enabled for the latter due to an LLVM bugs. See my above comment (#99069 (comment)) for more about these targets.
(By the way, on riscv64, LLVM does not generate 128-bit atomics even when the necessary feature is enabled (due to ABI compatibility). On loongarch64, LLVM generates 128-bit atomics only for a few operations when the necessary feature is enabled, but the implementation is quite incomplete, e.g., failed CAS may return corrupted values.)
docs: plan the claim-protocol prototype (M15), parking the non-blocki…
docs(waitable-queues): amend D-18 -- outcome stands, reasoning replaced