This issue was discussed at #106795
and at #106796 (comment)
Some functions in core::sync are defined to only compile if the target has 8-bit atomic support. While they should be compiled for all targets with atomic support.
This can cause unnecessary compilation issues when using a custom target json.
This can probably be solved by changing the definitions to
#[cfg(any(
target_has_atomic = "8",
target_has_atomic = "16",
target_has_atomic = "32",
target_has_atomic = "64",
target_has_atomic = "128",
target_has_atomic = "ptr"
))]
from
#[cfg(target_has_atomic = "8")]
like you can see at vadorovsky@041978b
Examples:
|
#[cfg(target_has_atomic = "8")] |
|
#[cfg_attr(miri, track_caller)] // even without panics, this helps for Miri backtraces |
|
unsafe fn atomic_add<T: Copy>(dst: *mut T, val: T, order: Ordering) -> T { |
|
#[cfg(target_has_atomic = "8")] |
|
#[cfg_attr(miri, track_caller)] // even without panics, this helps for Miri backtraces |
|
unsafe fn atomic_compare_exchange<T: Copy>( |
|
#[cfg(target_has_atomic = "8")] |
|
#[cfg_attr(miri, track_caller)] // even without panics, this helps for Miri backtraces |
|
unsafe fn atomic_nand<T: Copy>(dst: *mut T, val: T, order: Ordering) -> T { |
@vadorovsky @alessandrod
This issue was discussed at #106795
and at #106796 (comment)
Some functions in
core::syncare defined to only compile if the target has 8-bit atomic support. While they should be compiled for all targets with atomic support.This can cause unnecessary compilation issues when using a custom target json.
This can probably be solved by changing the definitions to
from
#[cfg(target_has_atomic = "8")]like you can see at vadorovsky@041978b
Examples:
rust/library/core/src/sync/atomic.rs
Lines 3014 to 3016 in bfffe40
rust/library/core/src/sync/atomic.rs
Lines 3047 to 3049 in bfffe40
rust/library/core/src/sync/atomic.rs
Lines 3133 to 3135 in bfffe40
@vadorovsky @alessandrod