Tracking issue for #[cfg(target_has_atomic = ...)] #32976

alexcrichton · 2016-04-14T23:54:49Z

Add integer atomic types Tracking issue: #32976 RFC: rust-lang/rfcs#1543 The changes to AtomicBool in the RFC are not included, they are in a separate PR (#32365).

sfackler · 2016-09-07T04:49:43Z

This is still blocked on some reasonable way to talk about platform-specificity in a more granular way than what we currently support.

Manishearth · 2016-10-04T20:06:09Z

Is there any reason why AtomicU32 would be hard to stabilize? We need a way to store multi-word bitflags in an atomic thingy. AtomicUsize won't work here since it's too large on 64 bit.

sfackler · 2016-10-05T00:53:08Z

What do you mean by "too large"?

Manishearth · 2016-10-05T03:46:10Z

Let's say I have a 64-bit bucket of flags. I need two atomic u32s to represent it. I can't use two usizes because that's too large on 64 bit.

Alternatively, let's say I have a 32-bit bucket of flags. This is on a struct where size matters. I need a u32, not something larger on 64-bit.

I guess I could cfg() it and abstract over it. That solves the first problem but not the second.

nagisa · 2016-10-05T14:11:45Z

@Manishearth 16-bit-usize targets would give you 16 bit atomic width. 100% savings over 32bit systems! (and potential loss of data)

There isn’t really much problem stabilising any of these IMO, but you’ll still have to CFG on target_has_atomic="32" in your code.

Manishearth · 2016-10-05T14:15:25Z

16-bit-usize targets would give you 16 bit atomic width.

ugh, these exist, right.

What do I have to do to get these stabilized? I'm okay with the cfgs.

I'm also okay with just u8 being stabilized, as long as I can pack it (not sure if this is possible with atomics)

Manishearth · 2016-12-15T21:22:49Z

What do I have to do to get these stabilized?

Any answer on this? cc @alexcrichton

The rfc looks like it's been completely implemented. IMO stabilizing it with target_has_atomic is fine, and we can add further granularity if we need in new rfcs.

alexcrichton · 2016-12-16T00:19:17Z

@Manishearth state hasn't changed from before. The libs team is essentially waiting for a conclusion on the scenarios story before stabilizing.

Manishearth · 2016-12-16T00:44:12Z

That discussion has stalled. Last I checked it seemed to mostly have come to consensus on the general idea? Who are we waiting on for a conclusion here? What would the ETA on this be? How can I help?

It also seems like that's mostly orthogonal to this. We can stabilize this using cfgs, and add scenarios later. They seem to be pretty compatible.

Manishearth · 2016-12-16T01:01:15Z

(After discussing in IRC, it seems like there have been a lot of recent discussions about this, and the libs team is currently moving on pushing this forward.)

archshift · 2017-01-15T06:36:37Z

Has there been any progress on this since?

bholley · 2017-02-04T00:22:45Z

Just FYI: Per [1], Gecko's Quantum CSS project is no longer blocked on this issue.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1336646

nagisa · 2017-05-07T20:09:20Z

We can stabilise AtomicU8 and AtomicI8 the same way we have stabilised AtomicBool – by using Atomic{I/U}Size operations everywhere.

thomcc · 2022-02-17T04:29:06Z

Should a tracking issue be filed for cfg(target_has_atomic_load_store) now that it's unstable?

Mark-Simulacrum · 2022-02-17T12:15:09Z

I filed one - #94039. Forgot to actually link it from here though.

ehuss · 2022-02-17T17:15:11Z

There's a small mention at atomic.rs that says it is still unstable. Would someone be willing to rewrite that paragraph to mention using cfg(target_has_atomic="...")?

tamird · 2022-06-23T15:02:01Z

This issue is closed, but several unstable annotations still refer to it:

rust/library/core/src/sync/atomic.rs

Lines 2467 to 2506 in 10f4ce3

    
           #[cfg(target_has_atomic_load_store = "128")] 
        
           atomic_int! { 
        
               cfg(target_has_atomic = "128"), 
        
               cfg(target_has_atomic_equal_alignment = "128"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               rustc_const_stable(feature = "const_integer_atomics", since = "1.34.0"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               cfg_attr(not(test), rustc_diagnostic_item = "AtomicI128"), 
        
               "i128", 
        
               "#![feature(integer_atomics)]\n\n", 
        
               atomic_min, atomic_max, 
        
               16, 
        
               "AtomicI128::new(0)", 
        
               i128 AtomicI128 ATOMIC_I128_INIT 
        
           } 
        
           #[cfg(target_has_atomic_load_store = "128")] 
        
           atomic_int! { 
        
               cfg(target_has_atomic = "128"), 
        
               cfg(target_has_atomic_equal_alignment = "128"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               rustc_const_stable(feature = "const_integer_atomics", since = "1.34.0"), 
        
               unstable(feature = "integer_atomics", issue = "32976"), 
        
               cfg_attr(not(test), rustc_diagnostic_item = "AtomicU128"), 
        
               "u128", 
        
               "#![feature(integer_atomics)]\n\n", 
        
               atomic_umin, atomic_umax, 
        
               16, 
        
               "AtomicU128::new(0)", 
        
               u128 AtomicU128 ATOMIC_U128_INIT 
        
           }

Is there another issue that should be linked there?

RalfJung · 2022-06-23T15:12:31Z

Good catch! integer_atomics needs a tracking issue. This one here seems to have been used for that (judging from #56753) but its title doesn't even reflect that... so it's probably best to open a new tracking issue and adjust the annotations.

Updates rust-lang#32976. Updates rust-lang#99069.

…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? `@RalfJung`

…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? ``@RalfJung``

Updates rust-lang#32976. Updates rust-lang#99069.

…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? ``@RalfJung``

Document the conditional existence of `alloc::sync` and `alloc::task`. `alloc` declares ```rust #[cfg(target_has_atomic = "ptr")] pub mod sync; ``` but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`. The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it. I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem. Note: `target_has_atomic` is [stabilized](rust-lang#32976) but [not yet documented in the reference](rust-lang/reference#1171).

Document the conditional existence of `alloc::sync` and `alloc::task`. `alloc` declares ```rust #[cfg(target_has_atomic = "ptr")] pub mod sync; ``` but there is no public documentation of this condition. This PR fixes that, so that users of `alloc` can understand how to make their code compile everywhere `alloc` does, if they are writing a library with impls for `Arc`. The wording is copied from `std::sync::atomic::AtomicPtr`, with additional advice on how to `#[cfg]` for it. I feel quite uncertain about whether the paragraph I added to `Arc`'s documentation should actually be there, as it is a distraction for anyone using `std`. On the other hand, maybe more reminders that no_std exists would benefit the ecosystem. Note: `target_has_atomic` is [stabilized](rust-lang/rust#32976) but [not yet documented in the reference](rust-lang/reference#1171).

juntyr · 2024-09-30T05:13:02Z

What is the current status of #[cfg(target_has_atomic = ...)]? Are there outstanding design or implementation concerns? Is stabilisation only waiting for someone to pick up the work?

Amanieu · 2024-10-01T09:39:48Z

target_has_atomic has been stable since 1.60.

juntyr · 2024-10-01T10:24:03Z

target_has_atomic has been stable since 1.60.

Whoops, my mistake, I meant [cfg(target_has_atomic_load_store = ...)] but was caught by #94039 (comment) where the feature is still named cfg_target_has_atomic and directs to here - thanks for your help and sorry for the noise

alexcrichton added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 14, 2016

alexcrichton mentioned this issue Apr 14, 2016

Add more integer atomic types rust-lang/rfcs#1543

Merged

Amanieu mentioned this issue Apr 17, 2016

Add integer atomic types #33048

Merged

bors added a commit that referenced this issue May 9, 2016

Auto merge of #33048 - Amanieu:integer_atomics, r=alexcrichton

af0a433

Add integer atomic types Tracking issue: #32976 RFC: rust-lang/rfcs#1543 The changes to AtomicBool in the RFC are not included, they are in a separate PR (#32365).

alexcrichton added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Jun 21, 2016

alexcrichton added the I-nominated label Aug 29, 2016

sfackler removed the I-nominated label Sep 7, 2016

cuviper mentioned this issue Nov 17, 2016

support find_first, find_last, position_first, and position_last rayon-rs/rayon#151

Closed

schuster mentioned this issue Dec 21, 2016

Implement find_first/last, position_first/last rayon-rs/rayon#189

Merged

This was referenced Jan 18, 2017

Provide a publicly-accessible Core ID tokio-rs/tokio-core#149

Merged

Max limit of loops per a lifetime of a process tokio-rs/tokio-core#151

Open

HadrienG2 mentioned this issue Mar 11, 2017

Switch to AtomicI8 once it's stabilized HadrienG2/triple-buffer#1

Closed

bors closed this as completed in 930fc4f Feb 17, 2022

nnethercote mentioned this issue Mar 4, 2022

Remove build.rs rust-lang/log#489

Closed

mriise mentioned this issue Mar 13, 2022

Add Webassembly, Atomics, and other things Elzair/page_size_rs#5

Open

kpreid mentioned this issue Jun 18, 2022

Document the conditional existence of alloc::sync and alloc::task. #98218

Merged

thomcc mentioned this issue Jun 30, 2022

Tracking issue for RFC 2523, #[cfg(accessible(::path::to::thing))] #64797

Open

3 tasks

tamird mentioned this issue Jul 8, 2022

Update integer_atomics tracking issue #99070

Merged

Dylan-DPC pushed a commit to Dylan-DPC/rust that referenced this issue Jul 9, 2022

Update integer_atomics tracking issue

a491d45

Updates rust-lang#32976. Updates rust-lang#99069.

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 9, 2022

Rollup merge of rust-lang#99070 - tamird:update-tracking-issue, r=Ral…

6816a8d

…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? `@RalfJung`

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 9, 2022

Rollup merge of rust-lang#99070 - tamird:update-tracking-issue, r=Ral…

3c35da2

…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? ``@RalfJung``

JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Jul 26, 2022

Update integer_atomics tracking issue

c413617

Updates rust-lang#32976. Updates rust-lang#99069.

JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Jul 26, 2022

Rollup merge of rust-lang#99070 - tamird:update-tracking-issue, r=Ral…

e151a09

…fJung Update integer_atomics tracking issue Updates rust-lang#32976. Updates rust-lang#99069. r? ``@RalfJung``

Lokathor mentioned this issue Nov 5, 2022

Conditionally compile in Arc Lokathor/bytemuck#140

Merged

badboy mentioned this issue Dec 11, 2022

Use target_has_atomic on Rust 1.60+ to enable atomic (de)serialization serde-rs/serde#2337

Merged

eric-seppanen mentioned this issue Jan 17, 2023

Tracking issue for integer_atomics #99069

Open

2 tasks

tgross35 mentioned this issue Apr 19, 2023

Suggestions for additional floating-point types rust-lang/rfcs#2629

Open

confident-OH mentioned this issue Jul 26, 2023

Need Cargo.lock file ProjectMitosisOS/mitosis-core#2

Open

KairusZhang mentioned this issue Oct 15, 2024

when i use cargo build command to build log ， i don't know what wrong and how to solve it? rust-lang/log#640

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for #[cfg(target_has_atomic = ...)] #32976

Tracking issue for #[cfg(target_has_atomic = ...)] #32976

alexcrichton commented Apr 14, 2016

sfackler commented Sep 7, 2016

Manishearth commented Oct 4, 2016

sfackler commented Oct 5, 2016

Manishearth commented Oct 5, 2016 •

edited

Loading

nagisa commented Oct 5, 2016 •

edited

Loading

Manishearth commented Oct 5, 2016

Manishearth commented Dec 15, 2016

alexcrichton commented Dec 16, 2016

Manishearth commented Dec 16, 2016 •

edited

Loading

Manishearth commented Dec 16, 2016

archshift commented Jan 15, 2017

bholley commented Feb 4, 2017

nagisa commented May 7, 2017

thomcc commented Feb 17, 2022

Mark-Simulacrum commented Feb 17, 2022

ehuss commented Feb 17, 2022

tamird commented Jun 23, 2022

RalfJung commented Jun 23, 2022

juntyr commented Sep 30, 2024

Amanieu commented Oct 1, 2024

juntyr commented Oct 1, 2024

Tracking issue for #[cfg(target_has_atomic = ...)] #32976

Tracking issue for #[cfg(target_has_atomic = ...)] #32976

Comments

alexcrichton commented Apr 14, 2016

sfackler commented Sep 7, 2016

Manishearth commented Oct 4, 2016

sfackler commented Oct 5, 2016

Manishearth commented Oct 5, 2016 • edited Loading

nagisa commented Oct 5, 2016 • edited Loading

Manishearth commented Oct 5, 2016

Manishearth commented Dec 15, 2016

alexcrichton commented Dec 16, 2016

Manishearth commented Dec 16, 2016 • edited Loading

Manishearth commented Dec 16, 2016

archshift commented Jan 15, 2017

bholley commented Feb 4, 2017

nagisa commented May 7, 2017

thomcc commented Feb 17, 2022

Mark-Simulacrum commented Feb 17, 2022

ehuss commented Feb 17, 2022

tamird commented Jun 23, 2022

RalfJung commented Jun 23, 2022

juntyr commented Sep 30, 2024

Amanieu commented Oct 1, 2024

juntyr commented Oct 1, 2024

Manishearth commented Oct 5, 2016 •

edited

Loading

nagisa commented Oct 5, 2016 •

edited

Loading

Manishearth commented Dec 16, 2016 •

edited

Loading