added test that fails without the revert

@rnk suggested on D70749 to do a simple revert of D69477. That's what this is.

Or just avoid sinking for these cases and do not generate llvm.assume calls.

It seems we have a variety of opinions on the right way to avoid the problem here, and many of them seem to require a fair bit of work. I'm all for getting to better semantics that avoid the problem we're seeing, but agreeing on a course of action, making the changes, testing it, and reviewing it seems like it would take a while. Meanwhile, we have a compiler that miscompiles cout << -10.0; Any chance we can get this change in to stop that from happening while we work on a better fix?

How was DAE able to replace an argument with undef which was fed to strlen? Is that the real bug?

Responding to @jdoerfert's comments:

moved undef check above other if statement

I'm assuming that addGetSourcecodeSteps takes care of checking out the correct revision. From a cursory look at LLVMBuildFactory and the Buildbot documentation, this appears to be the case.

Thanks! Removing unnecessary llvm:: prefix before commit.

@ruiu's comments (thanks!)

@MaskRay's comments. Thanks! I've changed the original code to match.

In D67457#1668678, @thakis wrote:

I don't think we should keep flag help texts in sync where it doesn't make sense. "Archive" is posix terminology. It's true that "wholearchive" has "archive" in it, but its help text on msdn is "Include All Library Object Files" :)

lgtm, thanks!

The help text for -start-lib and -end-lib matches that in the ELF linker. Please keep those matching by changing it there, too. Also, I think s/library/archive/, so that it matches the naming of -wholearchive.

Implemented ruiu's requests before committing. Thanks for reviewing!

• allow mixing -start-lib and -wholearchive:

comments by @ruiu and @MaskRay (thanks!)

• made AddMode an enum class
• simplified AddMode computation in OPT_INPUT case
• added missing std::moves
• use auto instead of explicitly naming LazyArchive

Primarily, this change adds a LazyObject Symbol kind, and a LazyObjFile InputFile kind. A LazyObject represents a symbol defined in a LazyObjFile, and a LazyObjFile is either a native object file or a bitcode file that we know of, but have not yet decided to link in. As with the LazyArchive symbols we already had, when we encounter both a lazy symbol and an Undefined symbol, we resolve this by linking in the file that defines the symbol, so the result is a Defined symbol.

fix places where I needed to add handling of LazyObject symbols

Seeing the code here, I see I still need to handle LazyObject in symbol resolution.

@ruiu, I'd like your opinion on this.

Related bug: https://bugs.llvm.org/show_bug.cgi?id=42717

changed flag name to -lto-obj-path:

Landed in r368612 / d47622.

'll call the Config field ltoObjPath, same as in the ELF linker.

After discussion in person, we decided on -lto-obj-path: similar to the naming in the ELF linker, and we'

@rnk, what do you think of the name I proposed?

In ELF, the config name is ltoObjPath, and the flag is -plugin-opt=obj-path=

Unfortunately, this causes some problems. It looks like the sections are created with different attributes than the original. This causes problems such as sections being writable when the original was read-only, including https://crbug.com/990942 where that causes program crashes. There is some more discussion on that bug report.

Heh, I just missed the revert. @jdenny, feel free to use this as inspiration.

replaced assert with llvm_unreachable

Linking ThinLTO chrome.dll with an undefined symbol:

added comment explaining BitcodeFiles::instances.empty() check

addressed @ruiu's comments

The basic idea here is:

don't process bitcode files in resolveRemainindUndefines

removed redundant check

Ready for review now.

rebase

Simplified after rebasing on top of r366127.

Fix typo pointed out by MaskRay (thanks!)

This was suggested on D64458.