Unused ivar checker: ivars referenced by lexically nested functions should not be flagged as unused.  Fixes <rdar://problem/7254495>.

llvm-svn: 89448

llvm-svn: 89447

llvm-svn: 89446

llvm-svn: 89445

tail call has been encountered.

llvm-svn: 89444

llvm-svn: 89443

construction.  WIP.

llvm-svn: 89442

llvm-svn: 89441

llvm-svn: 89440

just before codegen.

llvm-svn: 89439

constructor.  WIP.

llvm-svn: 89438

llvm-svn: 89437

llvm-svn: 89435

because if the results from getUnderlyingObject match, the values must
be from the same underlying object, even if we don't know what that
object is.

llvm-svn: 89434

llvm-svn: 89433

llvm-svn: 89430

llvm-svn: 89429

Fix debug code that assumes getBasicBlock never returns NULL.

llvm-svn: 89428

llvm-svn: 89426

  A::f

that occurs within a non-static member function with a type-dependent
"this", don't consider this to be a case for introduction of an
implicit "(*this)." to refer to a specific member function unless we
know (at template definition time) that A is a base class of *this.

There is some disagreement here between GCC, EDG, and Clang about the
handling of this case. I believe that Clang now has the correct,
literal interpretation of the standard, but have asked for
clarification (c++std-core-15483).

llvm-svn: 89425

llvm-svn: 89424

Fix codegen of conditional move of immediates. We were not making use of the immediate forms of cmov instructions at all.

llvm-svn: 89423

llvm-svn: 89422

careful about crazy methods of capturing pointers using comparisons.
Comparisons of identified objects with null in the default address
space are not captures. And, comparisons of two pointers within the
same identified object are not captures.

llvm-svn: 89421

llvm-svn: 89420

llvm-svn: 89419

llvm-svn: 89418

llvm-svn: 89417

generation.

llvm-svn: 89416

llvm-svn: 89414

llvm-svn: 89413

llvm-svn: 89412

llvm-svn: 89411

llvm-svn: 89410

rather than punting to a DependentSizedArrayType, tightening up our
type checking for template definitions. Thanks, John!

llvm-svn: 89407

Patch by Tobias Grosser!

llvm-svn: 89406

llvm-svn: 89404

assembly can confuse things utterly, as it's assumed that instructions in
inline assembly are 4 bytes wide. For Thumb mode, that's often not true,
so the calculations for when alignment padding will be present get thrown off,
ultimately leading to out of range constant pool entry references. Making
more conservative assumptions that padding may be necessary when inline asm
is present avoids this situation.

llvm-svn: 89403

appropriate lookup and simply can't resolve the referrent yet, and
"dependent scope" expressions, where we can't do the lookup yet because the
entity we need to look into is a dependent type.

llvm-svn: 89402

(radar 7409165).

llvm-svn: 89400