Fix overly strict volatile reads in Windows TLS implementation

Author: thomasdangl

library/std/src/sys/thread_local/guard/windows.rs

@@ -57,7 +57,7 @@
 //!
 //! We don't actually use the `/INCLUDE` linker flag here like the article
 //! mentions because the Rust compiler doesn't propagate linker flags, but
-//! instead we use a shim function which performs a volatile 1-byte load from
+//! instead we use a shim function which performs a 1-byte unaligned load from
 //! the address of the _tls_used symbol to ensure it sticks around.
 //!
 //! [1]: https://www.codeproject.com/Articles/8113/Thread-Local-Storage-The-C-Way
@@ -76,13 +76,13 @@ pub fn enable() {
     // When destructors are used, we need to add a reference to the _tls_used
     // symbol provided by the CRT, otherwise the TLS support code will get
     // GC'd by the linker and our callback won't be called.
-    unsafe { ptr::from_ref(&TLS_USED).read_volatile() };
+    unsafe { ptr::from_ref(&TLS_USED).read_unaligned() };
     // We also need to reference CALLBACK to make sure it does not get GC'd
     // by the compiler/LLVM. The callback will end up inside the TLS
     // callback array pointed to by _TLS_USED through linker shenanigans,
     // but as far as the compiler is concerned, it looks like the data is
     // unused, so we need this hack to prevent it from disappearing.
-    unsafe { ptr::from_ref(&CALLBACK).read_volatile() };
+    unsafe { ptr::from_ref(&CALLBACK).read_unaligned() };
 }
 
 #[unsafe(link_section = ".CRT$XLB")]