clang-format: Fix incorrect &/* detection.

Before:
  STATIC_ASSERT((a &b) == 0);

After:
  STATIC_ASSERT((a & b) == 0);

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204709 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes a bug in DynTypedNode.

Two DynTypedNodes can be equal if they do not have the same node type,
because DynTypedNodes for the same underlying object might have been
created from different types (for example, Decl vs VarDecl).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204722 91177308-0d34-0410-b5e6-96231b3b80d8
clang-cl: Forward /Gy or /Gy- when falling back to cl.exe

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204723 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Don't track retain counts of objects directly accessed through ivars.

A refinement of r198953 to handle cases where an object is accessed both through
a property getter and through direct ivar access. An object accessed through a
property should always be treated as +0, i.e. not owned by the caller. However,
an object accessed through an ivar may be at +0 or at +1, depending on whether
the ivar is a strong reference. Outside of ARC, we don't have that information,
so we just don't track objects accessed through ivars.

With this change, accessing an ivar directly will deliberately override the +0
provided by a getter, but only if the +0 hasn't participated in other retain
counting yet. That isn't perfect, but it's already unusual for people to be
mixing property access with direct ivar access. (The primary use case for this
is in setters, init methods, and -dealloc.)

Thanks to Ted for spotting a few mistakes in private review.

<rdar://problem/16333368>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204730 91177308-0d34-0410-b5e6-96231b3b80d8
clang-cl: make /Gy imply -fdata-sections in addition to -ffunction-sections

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204736 91177308-0d34-0410-b5e6-96231b3b80d8
Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math

In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.

Patch by Zinovy Nis!

Differential Revision: http://llvm-reviews.chandlerc.com/D3114

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204742 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Mark direct virtual bases as visted when building vtable paths

Fixes PR19240.  In retrospect, this is a fairly obvious bug.  :)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204744 91177308-0d34-0410-b5e6-96231b3b80d8
-fms-compatibility: Only form implicit member exprs for unqualified ids

If there are any scope specifiers, then a base class must be named or
the symbol isn't from a base class.

Fixes PR19233.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204753 91177308-0d34-0410-b5e6-96231b3b80d8
Use an option alias to implement -gmlt

Review feedback from Reid Kleckner on r203603.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204755 91177308-0d34-0410-b5e6-96231b3b80d8
PR19249: Don't forget to DiagnoseUseOfDecl for the implicit use of a variable
in a lambda capture.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204757 91177308-0d34-0410-b5e6-96231b3b80d8
[PGO] Add simplified branch weights for Objective-C for-collection loops.

Conceptually one of these loops is just a while-loop, but the actual code-gen
is more complicated. We don't instrument all the different control flow edges
to get accurate counts for each conditional branch, nor do I think it makes
sense to do so. Instead, make the simplifying assumption that the loop behaves
like a while-loop. Use the same branch weights for the first check for an
empty collection as would be used for the back-edge of a while loop, and use
that same weighting for the innermost loop, ignoring the possibility that there
may be some extra code to go fetch more elements.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204767 91177308-0d34-0410-b5e6-96231b3b80d8