This effectively disables the 'turbo' functionality of the greedy register
allocator where all new live ranges created by splitting would be reconsidered
as if they were originals.

There are two reasons for doing this, 1. It guarantees that the algorithm
terminates. Early versions were prone to infinite looping in certain corner
cases. 2. It is a 2x speedup. We can skip a lot of unnecessary interference
checks that won't lead to good splitting anyway.

The problem is that region splitting only gets one shot, so it should probably
be changed to target multiple physical registers at once.

Local live range splitting is still 'turbo' enabled. It only accounts for a
small fraction of compile time, so it is probably not necessary to do anything
about that.

llvm-svn: 126781

llvm-svn: 126780

Don't warn about unused values in ternary ?: expressions unless both the LHS and RHS are "unused" (side-effect free).

Patch by Justin Bogner!  Fixes PR 8282.

llvm-svn: 126779

template specialization types. There are still a few rough edges to
clean up with some of the parser actions dropping
nested-name-specifiers too early.

llvm-svn: 126776

llvm-svn: 126775

llvm-svn: 126774

llvm-svn: 126773

llvm-svn: 126772

llvm-svn: 126770

This makes the number of total tests equal to 201.

llvm-svn: 126769

llvm-svn: 126768

llvm-svn: 126767

llvm-svn: 126766

nested-name-speciciers within elaborated type names, e.g.,
 
  enum clang::NestedNameSpecifier::SpecifierKind

Fixes in this iteration include:

  (1) Compute the type-source range properly for a dependent template
  specialization type that starts with "template template-id ::", as
  in a member access expression

    dep->template f<T>::f()

  This is a latent bug I triggered with this change (because now we're
  checking the computed source ranges for dependent template
  specialization types). But the real problem was...

  (2) Make sure to set the qualifier range on a dependent template
  specialization type appropriately. This will go away once we push
  nested-name-specifier locations into dependent template
  specialization types, but it was the source of the
  valgrind errors on the buildbots.
  

llvm-svn: 126765

Patch by Dimitry Andric!

llvm-svn: 126763

llvm-svn: 126762

path.  This avoids accidentally including the wrong headers.

Patch by Dimitry Andric!

llvm-svn: 126761

ToolChain's FilePaths.  If clang is installed as a port in /usr/local,
it is *not* supposed to use /usr/local/lib by default, for example.

Additionally, there are no clang-related executables in either
/usr/libexec, or getDriver().Dir + "/../libexec", anymore, so remove
that from the ToolChain's ProgramPaths.

Patch by Dimitry Andric!

llvm-svn: 126760

llvm-svn: 126759

Add code to emulate LDRH (register) Arm instruction.

llvm-svn: 126758

retrieve the library paths from the ToolChain object instead.

Copy the relevant code from linuxtools::Link::ConstructJob(), and
replace the std::string stuff with llvm::StringRef, while we're here.

Patch by Dimitry Andric!

llvm-svn: 126757

one.

llvm-svn: 126756

llvm-svn: 126755

The prototype for objc_msgSend() is technically variadic - 
`id objc_msgSend(id, SEL, ...)`. 
But all method calls should use a prototype that matches the method, 
not the prototype for objc_msgSend itself().
// rdar://9048030

llvm-svn: 126754

location information for elaborated types. *sigh*

llvm-svn: 126753

llvm-svn: 126752

diagnose ignored qualifiers on return types, only assume that there is
a pointer chunk if the type is *structurally* a pointer type, not if
it's a typedef of a pointer type. Fixes PR9328/<rdar://problem/9055428>.

llvm-svn: 126751

a dependent template name rather than (indirectly and incorrectly)
trying to determine whether we can compute a context for the
nested-name-specifier. Fixes a GCC testsuite regression,
<rdar://problem/9068589>.

llvm-svn: 126749

information for qualifier type names throughout the parser to address
several problems.

The commit message from r126737:

Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".

Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.

With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.

llvm-svn: 126748

llvm-svn: 126746

in alphabetical order.

llvm-svn: 126745

intersection of the LHS and RHS ConstantRanges and return "false" when
the range is empty.

This simplifies some code and catches some extra cases.

llvm-svn: 126744

Chris Jefferson found this bug to pair/tuple introduced by a recent change to the draft that I missed.

llvm-svn: 126743

llvm-svn: 126742

more work to do here, "icmp ult (urem X, 10), 11" doesn't optimize away yet.
Fixes example 3 from PR9343!

llvm-svn: 126741

CC="clang -use-gold-plugin -emit-llvm"
CXX="clang++ -use-gold-plugin -emit-llvm"

llvm-svn: 126740

possible for these to show up due to metaprogramming both in unevaluated
contexts and compile-time dead branches.

Those aren't the bugs we're looking for.

llvm-svn: 126739

In preparation for fixing PR 6884, rework CFGElement to have getAs<> return pointers instead of fresh CFGElements.

- Also, consoldiate getDtorKind() and getKind() into one "kind".
- Add empty getDestructorDecl() method to CFGImplicitDtor.

llvm-svn: 126738

name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".

Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.

With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.

llvm-svn: 126737

the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.

On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.

llvm-svn: 126736