<div dir="ltr"><div dir="ltr">On Tue, Jul 16, 2019 at 7:04 AM Teresa Johnson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Usage of the builtin appears independent of LTO, see below.</div><div><br></div>With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which are all typically used to prevent usage of memcpy calls, we still always get a memcpy builtin in TlsDriverEntryPoint(). I see this even without -flto (e.g. try with just -emit-llvm).<div><br></div><div>I guess it is because this memcpy is not coming from the original source, but rather from the initialization code created by clang for the cryptopro_ext local variable. The code that generates that must not honor -fno-builtin. I see this even when I remove -flto (and this gets converted to a call to _memcpy in the final assembly with or without -fno-builtin).</div><div><br></div><div>I can't do the full LTO link with these options (don't have a windows linker I guess?), and have been unsuccessful in getting the failure with various other options I tried. I wanted to look at the merged LTO code with save-temps. </div><div><br></div><div>What happens to the builtin created by clang in LTO mode that causes lld to seg fault?</div></div></blockquote><div><br></div><div>I added some analysis to the bug. I think (but am not 100% confident) that we are lazily the memcpy bitcode file from an archive after LTO has already happened, leading to a crash later. I guess LLD should have some kind of check that ensures we don't load LTO objects after LTO has already run. </div></div></div>