Change:
Last successful build was on nightly-2018-06-29-x8664-unknown-linux-gnu rustc 1.28.0-nightly ( 2018-06-28). Next builds fails. I check nightly-2018-07-07-x8664-unknown-linux-gnu unchanged - rustc 1.29.0-nightly ( 2018-07-06) and 1.30.0-nightly ( 2018-09-22) I see some changes for msp430 between 2018-06-29 and 2018-07-07: - may it cause error?
Commit broke building for msp430, it parent () good. I build both version and check it. can you help?
Does the msp430 architecture not support atomic loads and stores (and I really mean atomic, not single instruction, those usually lower to atomic fence + load / store)? Or is this just an LLVM bug? I enabled atomic loads / stores on msp430 because (iirc) asked for it. In any case, we can undo to prevent this LLVM error but that would also remove the Atomic.{load,store} API. Alternatively, we can set the codegen option to true. That will turn all atomic operations into volatile operations. IIRC, that's fine for atomic load / stores in presence of interrupts (I might be wrong on this one because a "data synchronization barrier" instruction may still be needed) but unsound for atomic CAS operations in presence of interrupts. If we go down that route then we remove both (a) the possibility of supporting CAS ops in the future (which is probably fine since the ISA doesn't support it) and (b) the possibility of supporting multicore devices with this* target (but we can add another target to support those if they ever come into existence). What do think we should do here?
All loads and stores are atomic on MSP430. There are no fence instructions or atomic instructions. There's no CAS instruction either (as you mention) so we'd have to expand it to turning off interrupts, CASing, then turning them back on (which is kind of silly). I'm not really clear on what "atomic" vs "volatile" means in the context of Rust, but based on your paragraph above, sounds fine to me. ? EDIT: all load and store instructions - obviously 32-bit loads/stores are not atomic.
Actually, "volatile" was the wrong term to use as it doesn't describe the right semantics. With LLVM will lower into a [] plus the load instruction (I think) and with it will lower it into an atomic [] plus the load instruction. The links to the API have more details on the differences between the two kinds of fences. []: []:
Okay, great - a compile-time fence is exactly the semantics we want here. My vote is definitely for .
I took at stab at this (setting to ) and I still get an LLVM error while building core: It seems that the MSP430 backend doesn't support compiler fences. Minimal example, which can be replicated using nightly: Compare this to the ARM Cortex-M backend: Note that there's no instruction for the fence because this is a compiler fence. Given this fact the only path left to take here is to remove the API on MSP430 until its LLVM backend gains support for compiler fences.

Discussion:
const INITIAL_CAPACITY: usize = 7; // 2^3 - 1 const MINIMUM_CAPACITY: usize = 1; // 2 - 1 <ins> #[cfg(target_pointer_width = "16")] const MAXIMUM_ZST_CAPACITY: usize = 1 << (16 - 1); // Largest possible power of two </ins> #[cfg(target_pointer_width = "32")] const MAXIMUM_ZST_CAPACITY: usize = 1 << (32 - 1); // Largest possible power of two #[cfg(target_pointer_width = "64")]

no_integrated_as: true, // There are no atomic CAS instructions available in the MSP430 <del> // instruction set max_atomic_width: Some(16), </del> <ins> // instruction set, and the LLVM backend doesn't currently support // compiler fences so the Atomic* API is missing on this target. // When the LLVM backend gains support for compile fences uncomment // the `singlethread: true` line and set `max_atomic_width` to // `Some(16)`. max_atomic_width: Some(0), </ins> atomic_cas: false, <ins> // singlethread: true, </ins> // Because these devices have very little resources having an // unwinder is too onerous so we default to "abort" because the