llvm-svn: 65517

llvm-svn: 65512

Next step: making them more coherent.

llvm-svn: 65511

 - <rdar://problem/6622451> Bad x86_64 code gen for message call taking one argument.

llvm-svn: 65510

conditional branch predecessors.

llvm-svn: 65509

llvm-svn: 65508

llvm-svn: 65507

llvm-svn: 65504

llvm-svn: 65503

anymore.  If we want to reuse bits and pieces to add strict checking for 
constant initializers, we can dig them out of SVN history; the existing 
code won't be useful as-is.

llvm-svn: 65502

llvm-svn: 65501

variable declarations where applicable.  Also, a few fixes to 
TryToFixInvalidVariablyModifiedType for issues that this exposed.

llvm-svn: 65500

ADDS{D|S}rr_Int and MULS{D|S}rr_Int are not commutable. The users of these intrinsics expect the high bits will not be modified.

llvm-svn: 65499

llvm-svn: 65498

If an available register falls through to a succ block, unset the last kill. Sorry, it's impossible to reduce a sensible test case. It basically requires the moon and stars to align in order to cause a failure.

llvm-svn: 65497

llvm-svn: 65496

llvm-svn: 65493

llvm-svn: 65489

derive from a class template specialization, e.g.,

  class B : public A<int> { };

llvm-svn: 65488

llvm-svn: 65487

llvm-svn: 65486

llvm-svn: 65485

  vector<vector<double>> Matrix;

In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.

In C++0x, this token is always broken into two '>' tokens.

llvm-svn: 65484

scan-build now looks for ccc-analyzer first in the 'bin' subdirectory and then the directory where scan-build lives.

llvm-svn: 65483

llvm-svn: 65482

overly long ints, e.g. i96, into pieces at PHIs
and the nodes that feed into them; however big-endian
reverses the order of the pieces (for some reason), and
wasn't doing it the same way on both sides, so
the pieces didn't match and runtime failures ensued.
Fixes 188.ammp and sqlite3 on ppc32.

llvm-svn: 65481

expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y !=
10)' lazily, the cast to another integer type currently loses the symbolic
constraint. Eager evaluation of the constraint causes the paths to bifurcate and
eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address
<rdar://problem/6619921> until we have a better (more lazy approach) for
handling promotions/truncations of symbolic integer values.

llvm-svn: 65480

decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.

llvm-svn: 65478

specializations. In particular:

  - Make sure class template specializations have a "template<>"
    header, and complain if they don't.
  - Make sure class template specializations are declared/defined
    within a valid context. (e.g., you can't declare a specialization
    std::vector<MyType> in the global namespace).

llvm-svn: 65476

Do not automatically run the 'missing -dealloc' check until we have adequate time to make it much smarter (too much noise).

llvm-svn: 65474

code) when calling noreturn functions; general expression emission
isn't ready to do the right thing in all cases.

llvm-svn: 65473

 - PR3662.

llvm-svn: 65472

llvm-svn: 65471

 - No functionality change.

llvm-svn: 65470

Print variable's display name in dwarf DIE.

llvm-svn: 65468

  std::vector<int>::allocator_type

When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:

  template<> class Outer::Inner<int> { ... };

We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.

Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.

llvm-svn: 65467

global variable) out of GenerateStaticBlockVarDecl. 
 - No intended functionality change.
 - Prep for some mild cleanups and PR3662.

llvm-svn: 65466

llvm-svn: 65464

copied field by LLVM field if the record has a variable
sized field in it.  The problem is that the LLVM field
will not completely cover the variable sized gcc field.

llvm-svn: 65463

llvm-svn: 65462