Summary: Patch based on a patch by Ehsan Akhgari.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

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

llvm-svn: 181196

llvm-svn: 181195

llvm-svn: 181194

Some flags that are common to ASan/MSan/TSan/LSan have been moved to
sanitizer_common.

llvm-svn: 181193

[PowerPC] Fix memory corruption in AsmParser

As pointed out by Evgeniy Stepanov, assigning a std::string temporary
to a StringRef is not a good idea.  Rework MatchRegisterName to avoid
using the .lower routine.

llvm-svn: 181192

LLVM/Clang basically don't use such comments and for Google-style,
include-lines are explicitly exempt from the column limit. Also, for
most cases, where the column limit is violated, the "better" solution
would be to move the comment to before the include, which clang-format
cannot do (yet).

llvm-svn: 181191

print "//mach_kernel" if you are debugging an executable
in the top level directory.

llvm-svn: 181190

llvm-svn: 181189

llvm-svn: 181188

clang-format did not indent any declarations/definitions when breaking
after the type. With this change, it indents for all declarations but
does not indent for function definitions, i.e.:

Before:
const SomeLongTypeName&
some_long_variable_name;
typedef SomeLongTypeName
SomeLongTypeAlias;
const SomeLongReturnType*
SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }

After:
const SomeLongTypeName&
    some_long_variable_name;
typedef SomeLongTypeName
    SomeLongTypeAlias;
const SomeLongReturnType*
    SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }

While it might seem inconsistent to indent function declarations, but
not definitions, there are two reasons for that:
- Function declarations are very similar to declarations of function
type variables, so there is another side to consistency to consider.
- There can be many function declarations on subsequent lines and not
indenting can make them harder to identify. Function definitions
are already separated by their body and not indenting
makes the function name slighly easier to find.

llvm-svn: 181187

(Would sometimes optimize away conacts used to extend a vector with undef values)

llvm-svn: 181186

__alignof__ of a field.

This problem can only happen in C++11.

Also do some petty optimizations.

rdar://13784901

llvm-svn: 181185

llvm-svn: 181184

This seems to be more common in LLVM, Google and Chromium.

Before:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA :
    public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
    public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};

After:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    : public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
      public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};

llvm-svn: 181183

Before: template <class ... Ts> void Foo(Ts ... ts) { Foo(ts ...); }
After:  template <class... Ts> void Foo(Ts... ts) { Foo(ts...); }
llvm-svn: 181182

llvm-svn: 181181

pointers or not depending upon the function attributes.

llvm-svn: 181180

Looks like symbol resolution is not working on cygwin, the test fails
because __gxx_personality_v0 is not found.

llvm-svn: 181179

llvm-svn: 181178

Thanks Nick Lewycky for pointing this out.

llvm-svn: 181177

Use unknown results for places where it would be needed

llvm-svn: 181176

We used to disable constant merging not only if a constant is llvm.used, but
also if an alias of a constant is llvm.used. This change fixes that.

llvm-svn: 181175

Fix assert if __extension__ or _Generic is used when initializing a char array from a string literal.

llvm-svn: 181174

llvm-svn: 181173

We currently have no way to register new eh frames on ARM.

llvm-svn: 181172

llvm-svn: 181171

assignments in constant expressions. No significant functionality changes
(slight improvement to potential constant expression checking). 

llvm-svn: 181170

It looks like eh uses an unimplemented relocation on pp64

llvm-svn: 181169

llvm-svn: 181168

This gets exception handling working on ELF and Macho (x86-64 at least).
Other than the EH frame registration, this patch also implements support
for GOT relocations which are used to locate the personality function on
MachO.

llvm-svn: 181167

llvm-svn: 181166

I was not able to find a case (other than the fix in r181163) where this
makes a difference, but it is a more obviously correct API to have.

llvm-svn: 181165

Patch by Robert Wilhelm.

llvm-svn: 181164

This fixes pr14958. I will audit other calls to isExternCContext to see
if there are any similar bugs left.

llvm-svn: 181163

llvm-svn: 181162

indirect branch at the end of the BB. Otherwise if-converter, branch folding
pass may incorrectly update its successor info if it consider BB as fallthrough
to the next BB.

rdar://13782395

llvm-svn: 181161

llvm-svn: 181160

llvm-svn: 181159

llvm-svn: 181158

llvm-svn: 181157