-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
csky targets' atomic RMW is not lock-free #117306
Comments
Thanks! I think to fix LLVM to generate atomic instructions instead of libcalls is a better idea. The linux system and the gcc-toolchain of csky is not well maintained and the newest version of them is not open-source. Besides, there's many exsited devices with the system which is not suitable for upgrade. Therefore, I think to fix LLVM is a more realizable and practical way. |
(We don't have a CSky target label?) |
I assume this is about the csky-unknown-linux-gnuabiv2 target. |
and the csky-unknown-linux-gnuabiv2hf |
WG-prioritization assigning priority (Zulip discussion). @Dirreke AFAICS the compiler target @rustbot label -I-prioritize +P-low |
|
In csky, LLVM always generates libcalls (llvm/llvm-project@ec2de74), and atomic implementations are provided by libatomic.
rust/compiler/rustc_target/src/spec/csky_unknown_linux_gnuabiv2.rs
Line 15 in c7224e3
However, as mentioned in #115577 (comment), the atomic RMW implementation provided in libatomic.a is not lock-free.
And it violates what the standard library is intended to guarantee.
https://doc.rust-lang.org/nightly/std/sync/atomic/index.html#portability
Also, mixing lock-free load/store and non-lock-free RMW can cause data races.
To fix this, we would need to do one of the following:
It is not impossible to fix this on our end, but it is not very realistic as it would require writing a lot of inline assembly.
cc @Dirreke (mentioned because you are target maintainer)
@rustbot label +A-atomic +I-unsound
The text was updated successfully, but these errors were encountered: