> I'd kill for a "volatile" with guaranteed semantics in Rust. Possibly more than one person. The reason people ask for this is because they haven't thought th

> I'd kill for a "volatile" with guaranteed semantics in Rust. Possibly more than one person. The reason people ask for this is because they haven't thought this trough. Even if the compiler "preserves" all volatile operations, the HW does not. A trivial example is WASM. Rust can generate WASM code that, when using volatile, has many duplicated loads and stores in some order. Then the browser runs a WASM optimizer on the WASM code, which discovers that these instructions are redundant, and there you go, your program now doesn't do what you wanted anymore (formally, it never did). x86, ARM, PPC, FPGAs, GPUs, etc. all do this in HW as well. So while you could argue that, e.g., WASM should have volatile loads and stores, the same argument can be made at the next level down below, down to hardware. You'd need to ask every hardware vendor for some sort of serializing loads and stores, and people have done that, and vendors have implemented that, but then when users finally got what they wanted, they complained that they are too slow, so at that point they just stop using volatile and use atomics which is what they should have done in the first place.