Found by valgrind.

llvm-svn: 194797

llvm-svn: 194796

llvm-svn: 194795

Patch by Mikael Lyngvig

llvm-svn: 194794

llvm-svn: 194793

llvm-svn: 194792

llvm-svn: 194791

I still don't know what is causing our bootstrapped LTO buildbots to fail,
but llvm r194701 seems to be OK and I can't imagine that these changes could
cause the problem.

llvm-svn: 194790

I was able to successfully run a bootstrapped LTO build of clang with
r194701, so this change does not seem to be the cause of our failing
buildbots.

llvm-svn: 194789

llvm-svn: 194788

Also slightly reduces PECOFFLinkingContext's memory footprint (~128B).

llvm-svn: 194787

llvm-svn: 194786

llvm-svn: 194785

llvm-svn: 194784

This is to avoid this transformation in some cases:
fold (conv (load x)) -> (load (conv*)x)

On architectures that don't natively support some vector
loads efficiently casting the load to a smaller vector of
larger types and loading is more efficient.

Patch by Micah Villmow.

llvm-svn: 194783

representing the module import rather than making the module immediately
visible. This serves two goals:
 * It avoids making declarations in the module visible prematurely, if we
   walk past the #include during a tentative parse, for instance, and
 * It gives a diagnostic (although, admittedly, not a very nice one) if
   a header with a corresponding module is included anywhere other than
   at the top level.

llvm-svn: 194782

While the test would work with any compiled in target with object
emission support, it's nontrivial to formulate this condition in
lit, so a conservative restriction is used instead.

llvm-svn: 194781

This reverts commit 194701. Apple's bootstrapped LTO builds have been failing,
and this change (along with compiler-rt 194702-194704) is the only thing on
the blamelist.  I will either reappy these changes or help debug the problem,
depending on whether this fixes the buildbots.

llvm-svn: 194780

Apple's bootstrapped LTO builds have been failing, and these changes (along
with llvm 194701) are the only things on the blamelist.  I will either reapply
these changes or help debug the problem, depending on whether this fixes the
buildbots.

llvm-svn: 194779

llvm-svn: 194778

We can add multiple undefined atoms having the same name to the symbol table.
If such atoms are added, the symbol table compares their canBeNull attributes,
and select one having a stronger constraint. If their canBeNulls are the same,
the choice is arbitrary. Currently it choose the existing one.

This patch changes the preference, so that the symbol table choose the new one
if the new atom has a greater canBeNull or a fallback atom. This shouldn't
change the behavior except the case described below.

A new undefined atom may have a new fallback atom attribute. By choosing the new
atom, we can update the fallback atom during Core Linking. PE/COFF actually need
that. For example, _lseek is an alias for __lseek on Windows. One of an object
file in OLDNAMES.LIB has an undefined atom for _lseek with the fallback to
__lseek. When the linker tries to resolve _read, it supposed to read the file
from OLDNAMES.LIB and use the new fallback from the file. Currently LLD cannot
handle such case because duplicate undefined atoms with the same attributes are
ignored.

Differential Revision: http://llvm-reviews.chandlerc.com/D2161

llvm-svn: 194777

llvm-svn: 194776

until after we've referenced the operator; otherwise, we might pick up a
not-yet-deduced type.

llvm-svn: 194775

llvm-svn: 194774

This commit brings the module structure, argument order and
primitive names in Llvm_target in order with the rest of the bindings,
in preparation for adding TargetMachine API.

llvm-svn: 194773

llvm-svn: 194772

LLVMGetTargetFromName used to compare two char* strings directly.

llvm-svn: 194771

llvm-svn: 194770

LLVMGetTargetFromName was not yet present in an LLVM release,
so this does not break compatibility.

llvm-svn: 194769

llvm-svn: 194768

variable isn't really uninitialized, it's just not initialized yet.

llvm-svn: 194767

short form. Constant islands will expand them if they are out of range.
Since there is not direct object emitter at this time, it does not
have any material affect because the assembler sorts this out. But we
need to know for the actual constant island work. We track the difference
by putting # 16 inst in the comments.

llvm-svn: 194766

Bitcasts between address spaces are no longer allowed.

llvm-svn: 194765

This is similar to r194004: because we can't reason about the data structure
invariants of std::basic_string, the analyzer decides it's possible for an
allocator to be used to deallocate the string's inline storage. Just ignore
this by walking up the stack, skipping past methods in classes with
"allocator" in the name, and seeing if we reach std::basic_string that way.

PR17866

llvm-svn: 194764

This has no effect on user-visible output, but can be used by post-processing
tools that work with the generated HTML, rather than using CmpRuns.py's
interface to work with plists.

Patch by György Orbán!

llvm-svn: 194763

where we didn't. Extend our constant evaluation for __builtin_strlen to handle
any constant array of chars, not just string literals, to match.

llvm-svn: 194762

DbgVariable.

No functional change.

llvm-svn: 194761

Patch by Michele Scandale!

llvm-svn: 194760

Including only Debug.h did not cause a compilation error, but you couldn't
do anything (like writing something with <<) to raw_ostreams returned by
llvm::dbgs() or llvm::errs() without including raw_ostream.h. So including
it from Debug.h should make sense.

Differential Revision: http://llvm-reviews.chandlerc.com/D2183

llvm-svn: 194759

llvm-svn: 194757