Combined with typo correction's new ability to apply global/absolute nested
name specifiers to possible corrections, cases such as in PR12287 where the
desired function is being shadowed by a lexically closer function with the
same name but a different number of parameters will now include a FixIt.

On a side note, since the test for this change caused
test/SemaCXX/typo-correction.cpp to exceed the typo correction limit for
a single file, I've included a test case for exceeding the limit and added
some comments to both the original and part two of typo-correction.cpp
warning future editors of the files about the limit.

llvm-svn: 185881

llvm-svn: 185880

for now. 

llvm-svn: 185879

llvm-svn: 185878

Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).

There are two new classes:

lldb::SBModuleSpec
lldb::SBModuleSpecList

The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.

llvm-svn: 185877

llvm-svn: 185876

llvm-svn: 185875

llvm-svn: 185874

their equivalent property declaration. wip.

llvm-svn: 185873

The Mach-O linker has been able to support the weak-def bit on any symbol for
quite a while now. The compiler however continued to place these symbols into a
"coal" section, which required the linker to map them back to the base section
name.

Replace the sections like this:

  __TEXT/__textcoal_nt   instead use  __TEXT/__text
  __TEXT/__const_coal    instead use  __TEXT/__const
  __DATA/__datacoal_nt   instead use  __DATA/__data

<rdar://problem/14265330>

llvm-svn: 185872

llvm-svn: 185867

variable later in the class.

llvm-svn: 185866

llvm-svn: 185865

llvm-svn: 185863

llvm-svn: 185861

Ubuntu installs this as xdot, so finding xdot.py would fail.

llvm-svn: 185860

llvm-svn: 185859

[PowerPC] Always use "assembler dialect" 1

A setting in MCAsmInfo defines the "assembler dialect" to use.  This is used
by common code to choose between alternatives in a multi-alternative GNU
inline asm statement like the following:

  __asm__ ("{sfe|subfe} %0,%1,%2" : "=r" (out) : "r" (in1), "r" (in2));

The meaning of these dialects is platform specific, and GCC defines those
for PowerPC to use dialect 0 for old-style (POWER) mnemonics and 1 for
new-style (PowerPC) mnemonics, like in the example above.

To be compatible with inline asm used with GCC, LLVM ought to do the same.
Specifically, this means we should always use assembler dialect 1 since
old-style mnemonics really aren't supported on any current platform.

However, the current LLVM back-end uses:
  AssemblerDialect = 1;           // New-Style mnemonics.
in PPCMCAsmInfoDarwin, and
  AssemblerDialect = 0;           // Old-Style mnemonics.
in PPCLinuxMCAsmInfo.

The Linux setting really isn't correct, we should be using new-style
mnemonics everywhere.  This is changed by this commit.

Unfortunately, the setting of this variable is overloaded in the back-end
to decide whether or not we are on a Darwin target.  This is done in
PPCInstPrinter (the "SyntaxVariant" is initialized from the MCAsmInfo
AssemblerDialect setting), and also in PPCMCExpr.  Setting AssemblerDialect
to 1 for both Darwin and Linux no longer allows us to make this distinction.

Instead, this patch uses the MCSubtargetInfo passed to createPPCMCInstPrinter
to distinguish Darwin targets, and ignores the SyntaxVariant parameter.
As to PPCMCExpr, this patch adds an explicit isDarwin argument that needs
to be passed in by the caller when creating a target MCExpr.  (To do so
this patch implicitly also reverts commit 184441.)

llvm-svn: 185858

Use UsualArithmeticConversions unconditionally in analysis of
comparisons and conditional operators: the method performs
the usual arithmetic conversions if both sides are arithmetic, and
usual unary conversions if they are not.  This is just a cleanup
for conditional operators; for comparisons, it fixes the issue that
we would try to check isArithmetic() on an atomic type.

Also, fix GetExprRange() in SemaChecking.cpp so it deals with variables
of atomic type correctly.

Fixes PR15537.

llvm-svn: 185857

llvm-svn: 185856

Another bug found by llvm-stress! This fixes hitting
  llvm_unreachable("Invalid integer vector compare condition");
at the end of getVCmpInst in PPCISelDAGToDAG.

llvm-svn: 185855

llvm-svn: 185854

llvm-svn: 185853

Remove the implementation in include/llvm/Support/YAMLTraits.h.
Added a DenseMap type DITypeHashMap in DebugInfo.h:
  DenseMap<std::pair<StringRef, unsigned>, MDNode*>

llvm-svn: 185852

[ADT/NullablePtr] Allow implicit conversion of NullablePtr<OtherT> -> NullablePtr<T> if OtherT is derived from T.

llvm-svn: 185851

This reverts r185841 and relands r185831 without using
__has_attribute(const).

Clang prior to r161767 (between 3.1 and 3.2) does not accept
__has_attribute(const) due to rdar://10253857.  __const and __const__
are both keyword aliases of const, so they don't work either.

I was able to repro the buildbot failure using clang 3.1 and this patch
fixes it.  Various important versions of XCode use clang 2.9-ish, so
this workaround is necessary.

llvm-svn: 185850

llvm-svn: 185849

Update docs to say that a FunctionPass should not inspect other functions than the one being processed.
Please let me know if you disagree with this assessment (no one has yet, after asking on llvm-commits and LLVMDev) and I will revert.

llvm-svn: 185848

No functionality change. It should suffice to check the type of a debug info
metadata, instead of calling Verify.

llvm-svn: 185847

Fall back to by-element insert rather than building it up on the stack.

rdar://14351991

llvm-svn: 185846

This fixes "disassemble -m -n __printf".

llvm-svn: 185845

llvm-svn: 185844

 The symptom is seg-fault, and the root cause is that a SCEV contains a SCEVUnknown
which has null-pointer to a llvm::Value.

 This is how the problem take place:
 ===================================
  1). In the pristine input IR, there are two relevant instrutions Op1 and Op2, 
     Op1's corresponding SCEV (denoted as SCEV(op1)) is a SCEVUnknown, and
     SCEV(Op2) contains SCEV(Op1).  None of these instructions are dead.

     Op1 : V1 = ...
     ...
     Op2 : V2 = ... // directly or indirectly (data-flow) depends on Op1
    
  2) Optimizer (LSR in my case) generates an instruction holding the equivalent
     value of Op1, making Op1 dead. 
     Op1': V1' = ...
     Op1: V1 = ... ; now dead)
     Op2 : V2 = ... //Now deps on Op1', but the SCEV(Op2) still contains SCEV(Op1)

  3) Op1 is deleted, and call-back function is called to reset 
     SCEV(Op1) to indicate it is invalid. However, SCEV(Op2) is not 
     invalidated as well.

  4) Following pass get the cached, invalid SCEV(Op2), and try to manipulate it,
     and cause segfault. 

 The fix:
 ========
 It seems there is no clean yet inexpensive fix. I write to dev-list
soliciting good solution, unforunately no ack. So, I decide to fix this 
problem in a brute-force way:

  When ScalarEvolution::getSCEV is called, check if the cached SCEV 
contains a invalid SCEVUnknow, if yes, remove the cached SCEV, and
re-evaluate the SCEV from scratch.

  I compile buch of big *.c and *.cpp, fortunately, I don't see any increase
in compile time.

 Misc:
=====
 The reduced test-case has 2357 lines of code+other-stuff, too big to commit.

 rdar://14283433

llvm-svn: 185843

Since the pool indexes are necessarily sequential and contiguous, just
insert things in the right place rather than having to sort the sequence
after the fact.

No functionality change.

llvm-svn: 185842

This reverts r185831 and 185833.

llvm-svn: 185841

Another bug found by llvm-stress! This fixes crashing with:
  LLVM ERROR: Cannot select: v4f32 = frem ...

llvm-svn: 185840

Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 185839

libclc was defining and undefing GENTYPE and several other macros with
common names in its header files.  This was preventing applications from
defining macros with identical names as command line arguments to the
compiler, because the definitions in the header files were masking the
macros defined as compiler arguements.

Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 185838

Reviewed and Tested-by: Aaron Watry <awatry@gmail.com>

llvm-svn: 185837

Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 185836