I really should sort it or do something more sustainable, but I couldn't
work up the energy to do it... Sorry.

llvm-svn: 191832

llvm-svn: 191831

llvm-svn: 191830

This was broken when options were moved up in r191680. No test because this is
specific LLVMgold.so/libLTO.so.

Patch by Tom Roeder!

llvm-svn: 191829

line just to add or remove a single element. What I wouldn't give to
have clang-format here an be able to format this more densely without
caring...

Re-group and sort the entries while here to make the whole thing more
clear.

llvm-svn: 191828

llvm-svn: 191827

To support cross-endian and big-endian debugging avoid copying target
memory directly into host variables.

llvm-svn: 191826

Patch by Tom Roeder.

llvm-svn: 191825

Patch by Nicholas White.

llvm-svn: 191824

Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.

Patch by Greg Bedwell!

llvm-svn: 191823

sanitizer_common_interceptors.inc:1142:53: warning: invoking macro INTERCEPTOR argument 3: empty macro arguments are undefined in ISO C90 and ISO C++98 [enabled by default]

llvm-svn: 191822

llvm-svn: 191821

Patch by Alp Toker. Many thanks!

Original descriptions:
clang-format-diff incorrectly modifies unchanged lines due to an error
in diff parsing.

The unified diff format has a default line change count of 1, and 0 may
be specified to indicate that no lines have been added. This patch
updates the parser to accurately reflect the diff specification.

This also has the benefit of stabilising the operation so it will
produce the same output when run multiple times on the same changeset,
which was previously not the case.

No tests added because this script is not currently tested (though we
should look into that!)

llvm-svn: 191820

llvm-svn: 191819

llvm-svn: 191818

llvm-svn: 191817

llvm-svn: 191816

llvm-svn: 191815

libcxx doesn't build with -Werror because of #warnings in its source
code. But when libcxx is built as an external LLVM project, it inherits
LLVM build flags, breaking the build if LLVM_ENABLE_WERROR is enabled.

llvm-svn: 191814

llvm-svn: 191813

otherwise encoding fails after the last change in X86MCCodeEmitter.cpp.

llvm-svn: 191812

aren't yet happy with this config.

llvm-svn: 191811

llvm-svn: 191810

llvm-svn: 191809

when scalars are loaded / undergo lvalue-to-rvalue conversion.

llvm-svn: 191808

llvm-svn: 191807

llvm-svn: 191806

Also add some tests that there is actually a message and that the bug is
actually a hard error. This actually behaved correctly before, because:

- addTransition() doesn't actually add a transition if the new state is null;
  it assumes you want to propagate the predecessor forward and does nothing.
- generateSink() is called in order to emit a bug report.
- If at least one new node has been generated, the predecessor node is /not/
  propagated forward.

But now it's spelled out explicitly.

Found by Richard Mazorodze, who's working on a patch that may require this.

llvm-svn: 191805

This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
It's useful for the memory managers that are allocating a section to know what the name of the section is.  
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
what each allocation is for.  This allows clients that supply their own memory managers to do this.  
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
client.

This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
management C API).

llvm-svn: 191804

back in r173096 by Greg.  When constructing a g packet or parsing a G packet,
and we're iterate over our register list, skip registers that are actually
just slices of other, real, registers.  For instance, eax is 32-bits of rax
on x86_64.
<rdar://problem/15104187> 

llvm-svn: 191802

DW_TAG_pointer_type is updated to use DITypeRef.

Paired commit with r191800.

llvm-svn: 191801

is updated to use DITypeRef.

Move isUnsignedDIType and getOriginalTypeSize from DebugInfo.h to be static
helper functions in DwarfCompileUnit. We already have a static helper function
"isTypeSigned" in DwarfCompileUnit, and a pointer to DwarfDebug is added to
resolve the derived-from field. All three functions need to go across link
for derived-from fields, so we need to get hold of a type identifier map.

A pointer to DwarfDebug is also added to DbgVariable in order to resolve the
derived-from field.

Debug info verifier is updated to check a derived-from field is a TypeRef.
Verifier will not go across link for derived-from fields, in debug info finder,
we go across the link to add derived-from fields to types.

Function getDICompositeType is only used by dragonegg and since dragonegg does
not generate identifier for types, we use an empty map to resolve the
derived-from field.

When printing a derived-from field, we use DITypeRef::getName to either return
the type identifier or getName of the DIType.

A paired commit at clang is required due to changes to DIBuilder.

llvm-svn: 191800

comments issued with verbose assembly.
E.g., on a vector shuffle operation, disassembled output are:
* Without the option:
vpshufd $-0x79, (%rsp), %xmm0

* With the option:
vpshufd $-0x79, (%rsp), %xmm0   ## xmm0 = mem[3,1,0,2]

This part of <rdar://problem/14687488>.

llvm-svn: 191799

llvm-svn: 191798

that had 80-column violations. Remove spurious emacs mode markers on .cpp files.

llvm-svn: 191797

migration of headers which have become system headers by user having put
the .system_framework in the sdk directory.
// rdar://15066802

llvm-svn: 191796

llvm-svn: 191794

llvm-svn: 191793

and it is shared across CUs.

We add a few maps in DwarfDebug to map MDNodes for the type system to the
corresponding DIEs: MDTypeNodeToDieMap, MDSPNodeToDieMap, and
MDStaticMemberNodeToDieMap. These DIEs can be shared across CUs, that is why we
keep the maps in DwarfDebug instead of CompileUnit.

Sometimes, when we try to add an attribute to a DIE, the DIE is not yet added
to its owner yet, so we don't know whether we should use ref_addr or ref4.
We create a worklist that will be processed during finalization to add
attributes with the correct form (ref_addr or ref4).

We add addDIEEntry to DwarfDebug to be a wrapper around DIE->addValue. It checks
whether we know the correct form, if not, we update the worklist
(DIEEntryWorklist).

A testing case is added to show that we only create a single DIE for a type
MDNode and we use ref_addr to refer to the type DIE.

llvm-svn: 191792

llvm-svn: 191790