in C++, taking into account conversions to the "composite pointer
type" so that we can compare, e.g., a pointer to a derived class to a
pointer to a base class. 

Also, upgrade the "comparing distinct pointer types" from a warning to
an error for C++, since this is clearly an error. Turns out that we
hadn't gone through and audited this code for C++, ever. 

Fixes <rdar://problem/6816420>.

llvm-svn: 70829

- Fix retain checker test failures.
- Update retain checker to have annotations override default summary effects, not completely redefine them.

llvm-svn: 70828

 - This implements gcc style Objective-C interface layout (I
   think). Currently it is always off, there is no functionality
   change unless this is passed.
   
   For the curious, the deal is that gcc lays out the fields of a
   subclass as if they were part of the superclass. That is, the
   subclass fields immediately follow the super class fields instead
   of being padded to the alignment of the superclass structure.

 - Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
   llvm-gcc uses it in 32-bit only, for reasons which aren't clear
   yet. We probably want to switch to matching gcc, once this makes it
   through testing... my hope is that we can also fix llvm-gcc in
   order to maintain compatibility between the compilers.

llvm-svn: 70827

which is returned instead of a null pointer.  This helps centralize
the logic concerning "default effects".

llvm-svn: 70826

llvm-svn: 70825

We never compare summaries by their pointers, and we create only a
handful of them when analyzing a given function.

llvm-svn: 70824

hopefully, this fixes PR4144 without any regressions.

llvm-svn: 70823

via CollectObjCIvars.
 - In places where we need them, we should have the implementation and
   access the properties through it.

This is a fairly substantial functionality change: 
 1. @encode no longer encodes synthesized ivars, ever.

 2. The ivar layout bitmap no longer encodes information for
    synthesized ivars in superclasses. Well, actually I had already
    broken that, but it is intentional now.

We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.

Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.

I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.

llvm-svn: 70822

llvm-svn: 70821

  ThreadEdge directly.  This shares the code, but is just a refactoring.
* Make JumpThreading compute the set of loop headers and avoid threading
  across them.  This prevents jump threading from forming irreducible 
  loops (goodness) but also prevents it from threading in other cases that
  are beneficial (see the comment above FindFunctionBackedges).

llvm-svn: 70820

FindFunctionBackedges function.

llvm-svn: 70819

llvm-svn: 70818

llvm-svn: 70817

llvm-svn: 70816

The stack slots which share the same stack slot after coloring can, but do not have to, use the same register. In fact, they each may have different register class requirements.

llvm-svn: 70815

llvm-svn: 70814

llvm-svn: 70813

llvm-svn: 70812

llvm-svn: 70811

llvm-svn: 70810

llvm-svn: 70809

llvm-svn: 70808

 - The diagnostic is still poor, however. Doug, can you investigate?

 - Improved the test case to not depend on the file name, now it can
   be extended to actually check the formatting of the diagnostics
   (I'm hoping grep -A is portable here).

llvm-svn: 70807

stdint.h unless we are freestanding.

Any suggestions here are welcome.

llvm-svn: 70806

extension warning.

llvm-svn: 70805

llvm-svn: 70804

-Depend on DebugLocs for source line info.

llvm-svn: 70803

llvm-svn: 70800

llvm-svn: 70799

ivar layout.
 - The layout needs access to synthesized ivars.

llvm-svn: 70798

llvm-svn: 70797

llvm-svn: 70796

llvm-svn: 70795

llvm-svn: 70794

pasted token.

llvm-svn: 70793

llvm-svn: 70792

llvm-svn: 70791

is the empty set. :)  Thanks to Fritz for pointing this out.

llvm-svn: 70790

llvm-svn: 70789

throw exceptions.

llvm-svn: 70788