Change:
<del> Subproject commit 77a0125981b293260c9aec6355dff46ec707ab59 </del> <ins> Subproject commit 655a1467c98741e332b87661a9046877077ef4dc </ins>

Discussion:
The compilation of crates fails in various ways when a certain combination of rustflags is set. With this configuration I encountered the following issues: During installation of the crate (version 0.7.5), rustc crashes with a . See the detailled error output below. When installing , the resulting binary doesn't work correctly (). Using each rustflag individually does not result in this issue. I could reproduce this both on stable and the recent nightly, and with set to either , or (without trying more). : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryError during cargo install --force sd</summary<p</p</detailsAlso possibly relevant for .
I was able to reproduce the errors by specifying (in addition to ) the s or instead of setting a . Other s (e.g. ) work fine as far as I can tell. Possibly related to ?
Possibly related to ?
This was It may be good to figure out if this happens on lld on Linux: ping cleanup or if it's just Windows thing: ping windows Removing nomination also.
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Second didn't work ... ping windows
ping windows
Hey Windows Group! This bug has been identified as a good "Windows candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I spent some time trying to reproduce this, but wasn't able to. Can you provide more specific repro steps? Alternately, can you run under WinDbg, and show the stack trace and at the faulting address? What model CPU are you running on? Is it possible that the target features you're requesting are not available on that CPU?
I'm using a , so at least should be an exact match. AVX is definitely supported as well. I can still reproduce the with the current nightly during .

Here are the exact reproduction steps, with to limit the features used: Clean the registry to rule out interference with pre-existing caches: Install : There's nothing more I did to reproduce it. However, just like with the broken installation, it seems somewhat sporadic - about 1 out of 10 times the compilation succeeds. Meta: : : : I'm also using the latest Visual Studio Build Tools, if that's relevant. I'll investigate with WinDbg later today and report back.
Does not reproduce with on 2700X with: LLVM 10 from MSYS2 modify labels: -O-windows +O-windows-msvc
Also reproduces on a different system with a for me with the same reproduction steps as above. Here is the WinDbg output and the stack trace. I used the rustc command specified in the cargo error log. <details<summaryCommand output</summary</details<details<summaryStack trace</summary</detailsAdditionally the WinDbg output and the stack trace of running a miscompiled executable: <details<summaryCommand output</summary</details<details<summaryStack trace</summary
Looks like it's reading a value from TLS and adding an offset to use as a pointer that is not 32-byte aligned (): This is happening in the call which tries to read/write a thread local: LLVM seems to believe it should be 32 byte aligned, but as far as I can tell when ntdll is allocating the TLS slots they're 16 byte aligned Sounds like a similar issue to When built with lld-link there's no alignment specified for the TLS section in the DLL: But using the default msvc linker instead results in the correct alignment: Seems like an LLD bug?
Ah, that's great that you've found what appears to be the root cause. Are you / have you opened an issue for ? Is there more support needed from Windows devs?
I filed a bug:
Finally got around to digging into LLD. Fix at
I'm not sure, does this address the case of enabled AVX-512, where alignment should be even larger (64 byte instead of 32)?
Yes, it does. When the loader (ntdll) encounters a module (exe/dll) using TLS, it looks up the TLS directory in the PE image and uses the alignment specified there for all TLS data in the module.

So my patch just makes LLD save the max alignment of all .tls sections it encounters in the final binary. So that means as long as you're annotating your 's with the right alignment then it will work fine, i.e. using which is . In terms of allowed values, it's powers of 2 up to 8192 bytes with 16 as the default if unspecified.