Tracking issue for integer_atomics

[tamird]

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.

[RalfJung]

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.

[kadiwa4]

The unstable ATOMIC_*_INIT constants can be removed, right? Or should they be stabilized for consistency with the stable ATOMIC_*_INIT constants? (All of them are deprecated.)

[eric-seppanen]

The standard library docs for AtomicU128, etc. still point to #32976 instead of here.

[kadiwa4]

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-docs from rustup).

[eric-seppanen]

Apologies, I must have accidentally followed a link to somebody else's stale docs.

[gitmalong]

the trait bound std::sync::atomic::AtomicU128: mymod::_::_serde::Deserialize<'_> is not satisfied. Where to fill an issue for that?

[HayleyDeckers]

Now that #120820 has been merged, there are multiple T1 targets that support 128-bit atomics: x86_64-apple-darwin, x86_64-pc-windows-msvc and, x86_64-pc-windows-gnu.

as well as a few lower-tier targets such as aarch64-unknown-linux-musl, arm64e-apple-darwin and aarch64-unknown-uefi .

[HayleyDeckers]

@m-ou-se @Amanieu Are there any remaining blockers for this that need to be addressed?

[Amanieu]

This will stabilize AtomicI128 and AtomicU128 for AArch64 and x86_64 Windows/Apple targets. Notably, AtomicI128 is not available on x86_64 Linux targets because they target a version of x86_64 without cmpxchg16b. On those targets, you can check for support at runtime and use the cmpxchg16b intrinsic.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

@Amanieu Is this serving as a precedent for APIs that only work on a subset of targets?

To be clear, I'm all for exposing target-specific APIs wherever appropriate. I want to make sure we apply the policy this FCP is implying consistently. :)

[Amanieu]

Atomic types are already target-specific: AtomicU64 isn't available on some 32-bit targets for example. This isn't making things worse except that this difference is now noticeable on more common platforms.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[eric-seppanen]

AtomicI128 is not available on x86_64 Linux targets because they target a version of x86_64 without cmpxchg16b.

That's disappointing. Where can I learn more about this constraint and/or ideas for resolving it?

[ChrisDenton]

IIRC, the issue is that the Linux kernel, unlike Mac and Windows, does not require cmpxchg16b. It was suggested that we could split the x86_64 Linux targets in two, one targeting a higher baseline than the other. But that's a compiler issue, not a libs issue.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[taiki-e]

As for the correctness of the current implementations:

• AFAIK LLVM's aarch64 128-bit atomic support is (potentially) unsound in at least one case ([AArch64]: 128-bit Sequentially Consistent load allows reordering before prior store when armv8 and armv8.4 implementations are Mixed llvm/llvm-project#81978).
  That said, since LLVM 16 (llvm/llvm-project@10d34f5), assuming neither FFI nor -C target-{feature,cpu} are used, I believe inline assembly would have been required to reproduce this in Rust. ¹
  I think this is a potential stabilization blocker.
• AFAIK at least as of LLVM 17, there was another bug in big-endian aarch64 128-bit atomics, but I have not yet tested if LLVM 18 still has it.
  In any case, big-endian aarch64 is all tier 3, so it should not be a stabilization blocker.

As for future 128-bit atomic support on other targets (not stabilization blockers):

• If my understanding about the SGX target is correct, this is a target that requires Intel chip-specific technology, so I suspect that 128-bit atomics is always available (because all Intel x86_64 chips supports cmpxchg16b).
  • UPDATE: Opened Support 128-bit atomics on x86_64-fortanix-unknown-sgx #130552
• If we can add x86_64 Linux targets that require specific CPU features (something like x86_64_{v2,v3}-*. I believe this has been discussed several times in the past), then these x86_64 Linux targets could also support 128-bit atomics (without manually doing CPU feature detection or using a library that provide 128-bit atomics in such a way).
• Since LLVM 18 (llvm/llvm-project@c568927), 128-bit atomics are fully supported on s390x. (However, the current minimum external LLVM version is 17.) UPDATE: updated to 18 by Update the minimum external LLVM to 18 #130487
  • UPDATE: Done in Support 128-bit atomics on s390x #130558
• powerpc64 since power8 (such as powerpc64le-* targets) also supports 128-bit atomics, but the implementation by LLVM is still broken.

Footnotes

1. However, if future LLVM changes code generation to address performance issues with some chips (like https://github.com/taiki-e/portable-atomic/pull/89), it may be easily reproduced using Rust alone. ↩

[programmerjake]

Interestingly, in the online documentation the types don't show up at all

Reported as #130474

[cuviper]

• Since LLVM 18 (llvm/llvm-project@c568927), 128-bit atomics are fully supported on s390x. (However, the current minimum external LLVM version is 17.)

I'm updating the minimum to LLVM 18 in #130487.

We can try updating the s390x target spec separately though, after we make sure it's not also broken. :)

[beetrees]

Since generic Atomic<T> is in the process of being added (tracking issue), would it make sense to stabilise this as just Atomic<u128> and Atomic<i128>, rather than stabilising AtomicU128 and AtomicI128 only to have them made obsolete by Atomic<T> shortly afterwards?