search for: l1733

...; etc. For runtime functions defined in bitcode, we avoid the "double-LTO" scenario you describe by including them in the LTO link even if we can't prove they will be used. This is the handleLibcall code you pointed out. (https://github.com/llvm-mirror/lld/blob/master/ELF/Driver.cpp#L1733). As the comment there describes, we don't do this for runtime functions which are not defined in bitcode, to avoid other side-effects; instead we resolve those symbols after LTO. For the scenario I'm describing, though, it looks like the key decision here is made in SymbolTable::addShare...

I filed https://bugs.llvm.org/show_bug.cgi?id=42273 last night, about an inconsistency between LTO and non-LTO workflows. The basic scenario is that we have an object file which calls a function "foo", a static library that provides an implementation of "foo", and a shared library that also provides an implementation of "foo". Currently, whether lld chooses the