Thanks for the reply!

Is this intended to warn on code that casts a function taking a pointer to some non-void type to a function that takes a void*?

There are some possible follow-ups here:

1. Making sure CurLinkModule is set in all (or at least more) cases.
2. Addressing the FIXME about warnings and notes.

Thanks, everyone!

I avoided enumerating the cases to save space and to avoid pinning this down too much. My intention was to clarify that noimplicitfloat does not mean that no floating-point code will be generated under any circumstances, not necessarily to clarify exactly in which situations such code will or will not be generated. I'm happy to add the extra text, but before I do, I would like to get a second vote in favor of doing so vs. using the shorter text that I had written. @rnk, @craig.topper: What are your opinions?

Also specified that this inhibits the use of SIMD/vector registers
(which is true at least of x86_64 and armv8).

I just uploaded D104001, which makes essentially the same change to the code, but adds some additional rationale and test coverage. I would be happy to have either change move forward. I've added everyone who has commented on this diff to D104001 as well.

Thanks, everyone!

Thanks again for the comments. I've modified the test to use -NEXT as
requested.

Since D94962 was landed, we don't need this one anymore.

Thanks again.

implemented MaskRay's suggestions, added tests

also removed unused Format.h include

removed now unused <algorithm>

Indeed, there are not that many output sections. I simplified the code
by removing the sorting and formatting.

Can we not just make -gsplit-dwarf set the DwarfFissionKind without also looking at other things? That way, we don't have to worry about detecting the right mix of -g, -g2, -fthinlto-index, -x ir, bitcode input, etc. If there is some reason why this doesn't work, I would also like it to be expressed in a comment in the code so that someone doesn't come along and simplify/break the code later on.

In D94560#2497416, @jhenderson wrote:

I wonder whether the issue could be better solved by adding something (probably output section sizes as @grimar suggests) to the verbose output?

Thanks for the comments!

For Chrome on Chrome OS, this is https://crbug.com/1158215

As for the specific alternatives you suggested:

In D94560#2494674, @MaskRay wrote:

My feeling is similar to D94141: use either -M or --noinhibit-exec to get an output.

Ok, thanks for clarifying.

Thanks!

@pcc, do you have time for another look?

Thanks, Peter! I've implemented your suggestions.

@pcc, do you have time to take a look?

@tejohnson: The defs look like

Added a comment to (hopefully) better explain what the test does.

@dblaikie: My understanding is that LLVM reserves the right to assume that distinct globals never alias and optimize based on that (e.g. as mentioned under https://releases.llvm.org/10.0.0/docs/AliasAnalysis.html#the-basicaa-pass), and that declaring globals as zero-sized is the accepted way to avoid that (e.g. as mentioned in https://bugs.llvm.org/show_bug.cgi?id=31675#c5).

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