By default on OS X 10.8, we don't link with a crt1.o file and the linker
knows to use _main as the entry point.  But, when compiling with -pg, we
need to link with the gcrt1.o file, and the linker needs to be told to use
the "start" symbol as the entry point.  The -no_new_main linker option does
that last part.  <rdar://problem/11491405>

llvm-svn: 159683

llvm-svn: 159679

values:

- Return integer vectors in integer registers.
- Pass vector arguments in integer registers.
- Set an upper bound for argument alignment. The largest alignment is 8-byte
  for O32 and 16-byte for N32/64.

llvm-svn: 159676

e.g. ExprWithCleanups.

llvm-svn: 159674

llvm-svn: 159673

Patch by Andy Gibbs.

llvm-svn: 159665

may be destroying an ASTUnit while cleanupOnDiskMapAtExit is
getting called.

rdar://11781241

llvm-svn: 159664

llvm-svn: 159635

llvm-svn: 159634

(cf -Wunused-private-field and several other existing -field diagnostics.)

llvm-svn: 159633

initializer.

I really feel like Clang should warn about this, but I can't describe
a good reason. GCC will warn on this in some cases under
-Wsequence-point, but it actually seems like a false positive for that
warning....

llvm-svn: 159631

if we want to ignore a result, the Dest will be null.  Otherwise,
we must copy into it.  This means we need to ensure a slot when
loading from a volatile l-value.

With all that in place, fix a bug with chained assignments into
__block variables of aggregate type where we were losing insight into
the actual source of the value during the second assignment.

llvm-svn: 159630

llvm-svn: 159628

c-functions declared in implementation should have their 
parsing delayed until the end so, they can access forward
declared private methods. // rdar://10387088

llvm-svn: 159626

initialize any variable. This is extremely conservative, but is sufficient for
now.

llvm-svn: 159620

use scoped_lockable without putting unlock_function on the
destructor.

llvm-svn: 159609

This is NOT full-blown support for operator new, but removes some nasty
duplicated code introduced in r158784.

llvm-svn: 159608

llvm-svn: 159607

llvm-svn: 159606

llvm-svn: 159601

llvm-svn: 159596

...and instead add an accessor. We're not using this today, but it's something
that should probably stay in the source for potential clients, and it doesn't
cost a lot. (ObjCPropertyAccess is only created on the stack, and right now
there's only ever one alive at a time.)

This reverts r159581 / commit 8e674e1da34a131faa7d43dc3fcbd6e49120edbe.

llvm-svn: 159595

Now that we're only using -frewrite-includes rather than full preprocessing
when producing repro source files, we should also include command line macro
definitions in the repro script.

I don't have a test case for this because I'm not sure if/how I can open the
crash report file when the name is only known by scraping the crash report
output. Suggestions welcome if anyone thinks it'd be helpful.

llvm-svn: 159592

In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.

In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.

Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.

<rdar://problem/11662489> (again)

llvm-svn: 159591

When we're looking for redeclarations which might provide a definition in CodeGen, make sure we examine all the redeclarations.  PR13252.

llvm-svn: 159586

template instantiation. I wasn't able to reproduce this down to
anything small enough to put in our test suite, but it's "obviously"
okay to set the invalid bit earlier and precludes a
known-broken-but-not-marked-broken class from being used elsewhere.

llvm-svn: 159584

This member became unused in r159559.

llvm-svn: 159581

llvm-svn: 159579

we are encountering some scalability issues with memory usage.   The
appropriate long term fix is to make the analysis more scalable, but
this will at least prevent the analyzer swapping when
analyzing very large functions.

llvm-svn: 159578

in the call graph had been inlined but for whatever reason we did not inline some
of its callees.

Also, fix a related traversal bug where we meant to do a BFS of the callgraph but
instead were doing a DFS.

llvm-svn: 159577

the stack too often with 1024. Fixes <rdar://problem/11678534>.

llvm-svn: 159573

llvm-svn: 159563

llvm-svn: 159562

llvm-svn: 159561

llvm-svn: 159560

The preObjCMessage and postObjCMessage callbacks now take an ObjCMethodCall
argument, which can represent an explicit message send (ObjCMessageSend) or an
implicit message generated by a property access (ObjCPropertyAccess).

llvm-svn: 159559

Previously, the CallEvent subclass ObjCMessageInvocation was just a wrapper
around the existing ObjCMessage abstraction (over message sends and property
accesses). Now, we have abstract CallEvent ObjCMethodCall with subclasses
ObjCMessageSend and ObjCPropertyAccess.

In addition to removing yet another wrapper object, this should make it easy
to add a ObjCSubscriptAccess call event soon.

llvm-svn: 159558

This involved refactoring some common pointer-escapes code onto CallEvent,
then having MallocChecker use those callbacks for whether or not to consider
a pointer's /ownership/ as escaping. This still needs to be pinned down, and
probably we want to make the new argumentsMayEscape() function a little more
discerning (content invalidation vs. ownership/metadata invalidation), but
this is a good improvement.

As a bonus, also remove CallOrObjCMessage from the source completely.

llvm-svn: 159557

Both of these got uglier rather than cleaner because we don't have preCall and
postCall yet; properly wrapping a CallExpr in a CallEvent requires doing a bit
of deconstruction on the callee. Even when we have preCall and postCall we may
want to expose the current CallEvent to pre/postStmt<CallExpr>.

llvm-svn: 159556

This ended allowing quite a bit of cleanup, and some minor changes.

- CallEvent makes it easy to use hasNonZeroCallbackArg more aggressively, which
  we check in order to avoid false positives with callbacks that might release
  the object.
- In order to support this for functions which consume their arguments, there
  are two new ArgEffects: DecRefAndStopTracking and DecRefMsgAndStopTracking.
  These act just like StopTracking, except that if the object only had a
  return count of +1 it's now considered released instead (so we still get
  use-after-free messages).
- On the plus side, we no longer have to special-case
  +[NSObject performSelector:withObject:afterDelay:] and friends.
- The use of IdentifierInfos in the method summary cache is now hidden; only
  the ObjCInterfaceDecl gets passed around most of the time.
- Since we cache all "simple" summaries and check every function call, there is
  no real benefit to having NULL stand in for default summaries anymore.
- Whitespace, unused methods, etc.

Even more simplification to come when we get check::postCall and can unify all
these other post* checks.

llvm-svn: 159555