llvm-svn: 123872

failed to find a case where an enum context would make a difference, but
found PR9007 on the way.

llvm-svn: 123871

Set the thread state to "bland" before calling functions so they don't 
  inherit the pending signals and die.

llvm-svn: 123869

llvm-svn: 123868

declaration that name lookup actually found, so that we can use it for
access checking later on. Fixes <rdar://problem/8876150>.

llvm-svn: 123867

llvm-svn: 123866

with an invalid type then split the result and perform the overflow check
normally.

Fixes the 32-bit parts of rdar://8622122 and rdar://8774702.

llvm-svn: 123864

so allow it to propagate the failure outward. Fixes the crashing part
of <rdar://problem/8876150>.

llvm-svn: 123863

llvm-svn: 123862

overload resolution, so that we only use that number of call arguments
for partial ordering. Fixes PR9006, a recent regression.

llvm-svn: 123861

llvm-svn: 123860

llvm-svn: 123859

interval after an instruction. The leaveIntvAfter() method only adds liveness
from the instruction's boundary index to the inserted copy.

Ideally, SplitKit should be smarter about this, perhaps by combining useIntv()
and leaveIntvAfter() into one method that guarantees continuity.

llvm-svn: 123858

llvm-svn: 123857

llvm-svn: 123856

llvm-svn: 123855

Turn on the __has_feature switch for variadic templates, document
their completion, and put the ExtWarn into the c++0x-extensions
warning group.

llvm-svn: 123854

Region splitting includes loop splitting as a subset, and it is more generic.
The splitting heuristics for variables that are live in more than one block are
now:

1. Try to create a region that covers multiple basic blocks.
2. Try to create a new live range for each block with multiple uses.
3. Spill.

Steps 2 and 3 are similar to what the standard spiller is doing.

llvm-svn: 123853

ExtWarn. We want variadic templates to be usable in libc++/libstdc++
headers even when we're in C++98/03 mode, since it's the only clean
way to implement TR1 <functional>.

llvm-svn: 123852

reuse it for BlockDeclRefExpr. Do so, fixing the dependence calculate
for BlockDeclRefExpr.

llvm-svn: 123851

together. In particular: 
  - Handle the use of captured parameter pack names within blocks
  (BlockDeclRefExpr understands parameter packs now)
  - Handle the declaration and expansion of parameter packs within a block's
  parameter list, e.g., ^(Args ...args) { ... })
  - Handle instantiation of blocks where the return type was not
  explicitly specified. (unrelated, but necessary for my tests).

Together, these fixes should make blocks and variadic templates work
reasonably well together. Note that BlockDeclRefExpr is still broken
w.r.t. its computation of type and value dependence, which will still
cause problems for blocks in templates.

llvm-svn: 123849

llvm-svn: 123848

llvm-svn: 123846

a pack expansion, e.g., the parameter pack Values in:

  template<typename ...Types>
  struct Outer {
    template<Types ...Values>
    struct Inner;
  };

This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.

llvm-svn: 123845

llvm-svn: 123844

since different options can affect the run time.

llvm-svn: 123843

llvm-svn: 123842

making it way too big.

llvm-svn: 123841

llvm-svn: 123840

in pretending otherwise.

llvm-svn: 123839

by indvars through the scev expander.

trunc(add x, y) --> add(trunc x, y). Currently SCEV largely folds the other way
which is probably wrong, but preserved to minimize churn. Instcombine doesn't
do this fold either, demonstrating a missed optz'n opportunity on code doing
add+trunc+add.

llvm-svn: 123838

llvm-svn: 123837

a typo for !=). Fixes PR9001, from Hans Wennborg!

llvm-svn: 123836

definition, rather than complaining about it. Problem reported by
Marshall Clow.

llvm-svn: 123835

llvm-svn: 123834

llvm-svn: 123833

llvm-svn: 123832

llvm-svn: 123823

there's a respectable point of instantiation.  Also, make sure we do
this operation even when instantiating a dependently-typed variable.

llvm-svn: 123818

outermost array types and not on the element type.  Move the CanonicalType
member from Type to ExtQualsTypeCommonBase;  the canonical type on an ExtQuals
node includes the qualifiers on the ExtQuals.  Assorted optimizations enabled
by this change.

getQualifiers(), hasQualifiers(), etc. should all now implicitly look through
array types.

llvm-svn: 123817