Summary:
Preserve line breaks after function-like macro usages without
semicolon, e.g.:

QQQ(xxx)
class X {
};

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits

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

llvm-svn: 179064

I brazenly think this change is slightly simpler than r178793 because: 
  - no "state" in functor
  - "OpndPtrs[i]" looks simpler than "&Opnds[OpndIndices[i]]" 

  While I can reproduce the probelm in Valgrind, it is rather difficult to come up
a standalone testing case. The reason is that when an iterator is invalidated,
the stale invalidated elements are not yet clobbered by nonsense data, so the
optimizer can still proceed successfully. 

  Thank Benjamin for fixing this bug and generously providing the test case.

llvm-svn: 179062

llvm-svn: 179061

llvm-svn: 179060

Remove the custom lowering code dealing with it, disallow it in PNaclTargetInfo
and adjust tests accordingly.

llvm-svn: 179059

/Volumes/KernelDebugKit (the default mount point for the Kernel Debug
Kit dmgs).

llvm-svn: 179058

<rdar://problem/13559825> Further reduce template instantiation depth down to 256, since we're blowing the stack for a trivial "factorial" class template.

llvm-svn: 179057

When two template decls with the same name are used in this diagnostic,
force them to print their qualified names.  This changes the bad message of:

candidate template ignored: could not match 'array' against 'array'

to the better message of:

candidate template ignored: could not match 'NS2::array' against 'NS1::array'

llvm-svn: 179056

llvm-svn: 179055

This was committed without tests and contains obvious bugs. That's not
acceptable. It broke address sanitizer for most programs using glob(3).

llvm-svn: 179054

<rdar://problem/13540921> Fix a crasher when an Objective-C for-in loop gets a non-variable iteration declaration.

llvm-svn: 179053

llvm-svn: 179052

llvm-svn: 179051

llvm-svn: 179050

The idea is to indent according to operator precedence and pretty much
identical to how stuff would be indented with parenthesis.

Before:
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
             aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
             aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
             aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
             bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb +
             bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb &&
             aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
             aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
             ccccccccccccccccccccccccccccccccccccccccc;

After:
  bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
                   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
                           bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb +
                       bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb &&
               aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
                   ccccccccccccccccccccccccccccccccccccccccc;

llvm-svn: 179049

llvm-svn: 179048

llvm-svn: 179047

These checks are enabled with the -Wthread-safety-beta flag.

llvm-svn: 179046

llvm-svn: 179043

// rdar://12379114

llvm-svn: 179042

Change <cwchar> and <cstring> to look out for flags which may or may not be set by the C headers <wchar.h> and <string.h> indicating C support for the C++-altered wcschr, wcspbrk, wcsrchr, wcsstr, wmemchr, strchr, strpbrk, strrchr, memchr, and strstr.  This was already done in <cstring> for other platforms using other flags, so just had to add one more flag to the list there.

llvm-svn: 179041

In the comparison, both clang and GCC are popular and widely adopted.  This is no longer a win of GCC.

This whole doc should really be looked at.

llvm-svn: 179040

// rdar://12379114

llvm-svn: 179039

First feature is not CPU subtype anymore since r134127

llvm-svn: 179038

<rdar://problem/13540921> Cope with instantiations of the C++11 range-based for loop that end up being Objective-C fast enumeration loops.

llvm-svn: 179037

llvm-svn: 179036

<rdar://problem/13540921> Cope with deduced 'auto' in a C++11 for-range loop that is actually an Objective-C fast enumeration loop.

llvm-svn: 179035

llvm-svn: 179034

The costs are overfitted so that I can still use the legalization factor.

For example the following kernel has about half the throughput vectorized than
unvectorized when compiled with SSE2. Before this patch we would vectorize it.

unsigned short A[1024];
double B[1024];
void f() {
  int i;
  for (i = 0; i < 1024; ++i) {
    B[i] = (double) A[i];
  }
}

radar://13599001

llvm-svn: 179033

Add a regression test for the case where such behavior helps TSan:
  1. race is reported in the main module
  2. new shared library is loaded
  3. race is reported in the shared library

llvm-svn: 179032

llvm-svn: 179031

rdar://13521249

llvm-svn: 179030

<rdar://problem/12806802> Propagate access specifiers for conversion functions to the conversion function set eagerly.

This slightly propagates an existing hack that delays when we provide
access specifiers for the visible conversion functions of a class by
copying the available access specifier early. The only client this
affects is LLDB, which tends to discover and add conversion functions
after the class is technically "complete". As such, the only
observable difference is in LLDB, so the testing will go there.

llvm-svn: 179029

llvm-svn: 179027

PowerPC has a conditional branch to the link register (return) instruction: BCLR.
This should be used any time when we'd otherwise have a conditional branch to a
return. This adds a small pass, PPCEarlyReturn, which runs just prior to the
branch selection pass (and, importantly, after block placement) to generate
these conditional returns when possible. It will also eliminate unconditional
branches to returns (these happen rarely; most of the time these have already
been tail duplicated by the time PPCEarlyReturn is invoked). This is a nice
optimization for small functions that do not maintain a stack frame.

llvm-svn: 179026

llvm-svn: 179023

llvm-svn: 179022

llvm-svn: 179021

llvm-svn: 179020

llvm-svn: 179019