where we hash, compare and fold, instead of one iteration where we build up
the hash buckets and a second one to fold.

llvm-svn: 112582

terrible, FIXME left to do a proper job of diagnosing this.

llvm-svn: 112581

llvm-svn: 112580

declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.

llvm-svn: 112579

Teach the CFGBuilder not do die on CXXBindTemporaryExpr, CXXOperatorCallExpr. Fixes a Boost.Graph crasher.

llvm-svn: 112578

llvm-svn: 112577

Remove r111665, which implemented store-narrowing in InstCombine.  Chris discovered a miscompilation in it, and it's not easily
fixable at the optimizer level. I'll investigate reimplementing it in DAGCombine.

llvm-svn: 112575

llvm-svn: 112571

Use X86ISD::MOVSS and MOVSD to represent the movl mask pattern, also fix the handling of those nodes when seeking for scalars inside vector shuffles

llvm-svn: 112570

llvm-svn: 112569

llvm-svn: 112568

Eventually, we want to disable physreg coalescing completely, and let the
register allocator do its job using hints.

This option makes it possible to measure the impact of disabling physreg
coalescing.

llvm-svn: 112567

llvm-svn: 112566

Add a forgotten place where the enclosing namespace set matters, plus a big testcase for inline namespace fun.

llvm-svn: 112565

llvm-svn: 112564

Rename DeclContext::getLookupContext to getRedeclContext and change its semantics slightly. No functionality change in the absence of inline namespaces. Also, change a few places where inline namespaces actually make a difference to be prepared for them.

llvm-svn: 112563

Decl::getEnclosingNamespaceContext has no reason to explicitly skip transparent contexts, and would be wrong to do so with inline namespaces.

llvm-svn: 112562

instantiating the parameters. In a perfect world, this wouldn't
matter, and compilers are free to instantiate in any order they
want. However, every other compiler seems to instantiate the return
type first, and some code (in this case, Boost.Polygon) depends on
this and SFINAE to avoid instantiating something that shouldn't be
instantiated.

We could fight this battle, and insist that Clang is allowed to do
what it does, but it's not beneficial: it's more predictable to
instantiate this way, in source order. When we implement
late-specified return types, we'll need to instantiate the return type
last when it was late-specified, hence the FIXME.

We now compile Boost.Polygon properly.

llvm-svn: 112561

llvm-svn: 112560

things we can't handle.

llvm-svn: 112559

llvm-svn: 112558

with the descriptions of Mod and Ref.

llvm-svn: 112557

process being debugged in the TestBase.tearDown() instead of letting it continue
and finish.

llvm-svn: 112556

llvm-svn: 112555

llvm-svn: 112554

llvm-svn: 112553

llvm-svn: 112552

of that parameter, reduce the level by the number of active template
argument lists rather than by 1. The number of active template
argument lists is only > 1 when we have a class template partial
specialization of a member template of a class template that itself is
a member template of another class template. 

... and Boost.MSM does this. Fixes PR7669.

llvm-svn: 112551

Re-apply r112539, being more careful to respect the return values of the constant folding methods.  Additionally,
use the ConstantExpr::get*() methods to simplify some constant folding.

llvm-svn: 112550

llvm-svn: 112549

parameter.

llvm-svn: 112548

of os command to lldbtest.TestBase.system() method.

llvm-svn: 112547

scheduling opportunities (extra instruction can go in between
MOVT / MOVW pair removing the stall).

llvm-svn: 112546

llvm-svn: 112545

llvm-svn: 112543

them from test cases instead of issuing "make clean; make ..." os command.

llvm-svn: 112542

llvm-svn: 112541

persistent variables were staying around too long.
This caused the following problem:

- A persistent result variable is created for the
  result of an expression.  The pointer to the
  corresponding Decl is stored in the variable.

- The persistent variable is looked up during
  struct generation (correctly) using its Decl.

- Another expression defines a new result variable
  which happens to have a Decl in the same place
  as the original result variable.

- The persistent variable is looked up during
  struct generation using its Decl, but the old
  result variable appears first in the list and
  has the same Decl pointer.

The fix is to destroy parser-specific data when
it is no longer valid.

Also improved some logging as I diagnosed the
bug.

llvm-svn: 112540

Fixes and cleanups pointed out by Chris.  In general, be careful to handle 0 results from ComputeValueKnownInPredecessors
(indicating undef), and re-use existing constant folding APIs.

llvm-svn: 112539

is meant to do exactly the same thing. Thanks to Jim Grosbach for pointing this
out! :-)

llvm-svn: 112538