diff options
| -rw-r--r-- | src/libcore/intrinsics.rs | 9 | ||||
| -rw-r--r-- | src/libcore/ptr.rs | 12 |
2 files changed, 18 insertions, 3 deletions
diff --git a/src/libcore/intrinsics.rs b/src/libcore/intrinsics.rs index fdca8d00d7a..ad776c8605a 100644 --- a/src/libcore/intrinsics.rs +++ b/src/libcore/intrinsics.rs @@ -1044,20 +1044,23 @@ extern "rust-intrinsic" { /// a size of `count` * `size_of::<T>()` and an alignment of /// `min_align_of::<T>()` /// - /// The volatile parameter is set to `true`, so it will not be optimized out. + /// The volatile parameter is set to `true`, so it will not be optimized out + /// unless size is equal to zero. pub fn volatile_copy_nonoverlapping_memory<T>(dst: *mut T, src: *const T, count: usize); /// Equivalent to the appropriate `llvm.memmove.p0i8.0i8.*` intrinsic, with /// a size of `count` * `size_of::<T>()` and an alignment of /// `min_align_of::<T>()` /// - /// The volatile parameter is set to `true`, so it will not be optimized out. + /// The volatile parameter is set to `true`, so it will not be optimized out + /// unless size is equal to zero.. pub fn volatile_copy_memory<T>(dst: *mut T, src: *const T, count: usize); /// Equivalent to the appropriate `llvm.memset.p0i8.*` intrinsic, with a /// size of `count` * `size_of::<T>()` and an alignment of /// `min_align_of::<T>()`. /// - /// The volatile parameter is set to `true`, so it will not be optimized out. + /// The volatile parameter is set to `true`, so it will not be optimized out + /// unless size is equal to zero. pub fn volatile_set_memory<T>(dst: *mut T, val: u8, count: usize); /// Perform a volatile load from the `src` pointer. diff --git a/src/libcore/ptr.rs b/src/libcore/ptr.rs index 60cf1a20530..b37e3a5236d 100644 --- a/src/libcore/ptr.rs +++ b/src/libcore/ptr.rs @@ -384,6 +384,12 @@ pub unsafe fn write_unaligned<T>(dst: *mut T, src: T) { /// over time. That being said, the semantics will almost always end up pretty /// similar to [C11's definition of volatile][c11]. /// +/// Compiler shouldn't change relative order or number of volatile memory +/// operations, however this implies that memory operation actually takes place. +/// If a zero-sized type is used in a specialisation of `read_volatile`, value +/// is known at any time and can not be modified outside of program control. +/// In this case such operation may be omitted by compiler backend. +/// /// [c11]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf /// /// # Safety @@ -427,6 +433,12 @@ pub unsafe fn read_volatile<T>(src: *const T) -> T { /// over time. That being said, the semantics will almost always end up pretty /// similar to [C11's definition of volatile][c11]. /// +/// Compiler shouldn't change relative order or number of volatile memory +/// operations, however this implies that memory operation actually takes place. +/// If a zero-sized type is used in a specialisation of `write_volatile`, value +/// is known at any time and can not be modified outside of program control. +/// In this case such operation may be omitted by compiler backend. +/// /// [c11]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf /// /// # Safety |