llvm-svn: 151108

llvm-svn: 151107

any implementation in tu was not being translated.

llvm-svn: 151106

This test case was way too strict, matching the entire assembly output.
Every non-trivial change to the ppc backend  or -O0 pipeline required
the test to be updated.

It should be replaced with a test of the specific vaarg feature.

llvm-svn: 151105

Even if a call instruction has %SP<imp-def> operands, it doesn't change
the value of the stack pointer.

llvm-svn: 151104

llvm-svn: 151103

llvm-svn: 151102

that 'this' can be used in the brace-or-equal-initializer of a
non-static data member, and C++11 [expr.prim.lambda]p9, which says
that lambda expressions not in block scope can have no captures, side
fully with C++11 [expr.prim.general]p4 by allowing 'this' to be
captured within these initializers. This seems to be the intent of
non-static data member initializers.

llvm-svn: 151101

llvm-svn: 151100

bundles. This method takes a bundle start and an MI being bundled, and makes
the intervals for the MI's operands appear to start/end on the bundle start.

Also fixes some minor cosmetic issues (whitespace, naming convention) in the
HMEditor code.

llvm-svn: 151099

rdar://10493979

llvm-svn: 151098

Part of rdar://10493979 where it reduces by about .5% (10k)

llvm-svn: 151097

itself crashes.

llvm-svn: 151095

prefixes. It seems only crtbegin.o uses the strange formatting.

llvm-svn: 151094

they'll be simple enough to simulate, and to reduce the chance we'll encounter
equal but different simple pointer constants.

This removes the symptoms from PR11352 but is not a full fix. A proper fix would
either require a guarantee that two constant objects we simulate are folded
when equal, or a different way of handling equal pointers (ie., trying a
constantexpr icmp on them to see whether we know they're equal or non-equal or
unsure).

llvm-svn: 151093

the linker toolchainness a bit more thoroughly. It used to work this
way, but hit buildbot issues. Hopefully subsequent fixes have addressed
those problems, but I'll be watching the bots.

llvm-svn: 151090

rdar://problem/10904479

llvm-svn: 151089

Modernize conversion to bool to the explicit bool conversion operator (library wide).  This fixes http://llvm.org/bugs/show_bug.cgi?id=12058.

llvm-svn: 151088

up the build enviroment.

llvm-svn: 151087

llvm-svn: 151085

Modernize relational operators for shared_ptr and unique_ptr.  This includes adding support for nullptr, and using less<T*>.  Fixes http://llvm.org/bugs/show_bug.cgi?id=12056.

llvm-svn: 151084

llvm-svn: 151083

expression after we've finished the function body of the corresponding
function call operator. Otherwise, ActOnFinishFunctionBody() will see
the (unfinished) evaluation context of the lambda expression
itself. Fixes PR12031.

llvm-svn: 151082

is non-null when diagnosing a broken attempt to write a for-range-statement.

llvm-svn: 151081

When calling a non variadic format function(vprintf, vscanf, NSLogv, …), warn if the format string argument is a parameter that is not itself declared as a format string with compatible format.

llvm-svn: 151080

llvm-svn: 151079

llvm-svn: 151077

arguments. There are two aspects to this:

  - Make sure that when marking the declarations referenced in a
  default argument, we don't try to mark local variables, both because
  it's a waste of time and because the semantics are wrong: we're not
  in a place where we could capture these variables again even if it
  did make sense.
  - When a lambda expression occurs in a default argument of a
  function template, make sure that the corresponding closure type is
  considered dependent, so that it will get properly instantiated. The
  second bit is a bit of a hack; to fix it properly, we may have to
  rearchitect our handling of default arguments, parsing them only
  after creating the function definition. However, I'd like to
  separate that work from the lambdas work.

llvm-svn: 151076

llvm-svn: 151074

llvm-svn: 151072

llvm-svn: 151071

llvm-svn: 151069

incorrect values and also fire an assertion.

llvm-svn: 151066

llvm-svn: 151059

that's installed.

llvm-svn: 151058

llvm-svn: 151057

llvm-svn: 151056

This transformation is not safe in some pathological cases (signed icmp of pointers should be an
extremely rare thing, but it's valid IR!). Add an explanatory comment.

Kudos to Duncan for pointing out this edge case (and not giving up explaining it until I finally got it).

llvm-svn: 151055

and into StringRef.cpp, which is where the other StringRef stuff is.

llvm-svn: 151054

llvm-svn: 151053