llvm-svn: 220377

llvm-svn: 220376

llvm-svn: 220375

llvm-svn: 220374

Before:
  auto doSomething(Aaaaaa* aaaaaa) -> decltype(aaaaaa -> f()) {}

After:
  auto doSomething(Aaaaaa* aaaaaa) -> decltype(aaaaaa->f()) {}

llvm-svn: 220373

New functions to give client applications to tools to discover target byte sizes
for addresses prior to ReadMemory. Also added GetPlatform and ReadMemory to the
SBTarget class, since they seemed to be useful utilities to have.

Each new API has had a test case added.

http://reviews.llvm.org/D5867

llvm-svn: 220372

It's not handling phis.

llvm-svn: 220371

llvm-svn: 220370

llvm-svn: 220369

This fails the verifier with:
"Expected a VCSrc_32 register, but got a VReg_1 register"

llvm-svn: 220368

llvm-svn: 220364

If a templated class is not instantiated, then the AST for it could be missing
some things that would throw the field checker off.  Wait until specialization
before emitting these warnings.

llvm-svn: 220363

This renames the Windows toolchain to MSVCToolChain.  This is a preparatory step
for adding a CrossWindowsToolChain which uses clang/libc++/(ld/lld) without the
standard GCC toolchain lookup.  NFC.

llvm-svn: 220362

Thanks to Filipe Cabecinhas for the report.

llvm-svn: 220361

gcc's (4.7, I think) -Wcomment warning is not "as smart" as clang's and
warns even if the line right after the backslash-newline sequence only has
a line comment that starts at the beginning of the line.

llvm-svn: 220360

Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.

This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.

llvm-svn: 220359

BreakpointLocation::ShouldStop.  That worked but wasn't really right,
since there's nothing to guarantee that won't get called more than
once.  So this change moves that responsibility to the StopInfoBreakpoint
directly, and then it uses the BreakpointSite to actually do the bumping.

Also fix a test case that was assuming if you had many threads running some 
code with a breakpoint in it, the hit count when you stopped would always be
1.  Many of the threads could have hit it at the same time...

<rdar://problem/18577603>

llvm-svn: 220358

llvm-svn: 220357

llvm-svn: 220356

llvm-svn: 220355

llvm-svn: 220354

llvm-svn: 220353

llvm-svn: 220352

ParamTLS (shadow for function arguments) is of limited size. This change
makes all arguments that do not fit unpoisoned, and avoids writing
past the end of a TLS buffer.

llvm-svn: 220351

This is a follow-up patch for r220333. r220333 renames exported symbols.
That raised another issue; if we have both decorated and undecorated names
for the same symbol, we'll end up have two duplicate exported symbol
entries.

This is a fix for that issue by removing duplciate entries.

llvm-svn: 220350

This seems to have caused PR21330.

llvm-svn: 220349

All compiler generated mach-o object files are marked with MH_SUBSECTIONS_VIA_SYMBOLS.
But hand written assembly files need to opt-in if they are written correctly.
The flag means the linker can break up a sections at symbol addresses and
dead strip or re-order functions.

This change recognizes object files without the flag and marks its atoms as
not dead strippable and adds a layout-after chain of references so that the
atoms cannot be re-ordered.

llvm-svn: 220348

On AArch64, GOT references are page relative (ADRP + LDR), so they can't be
applied until we know exactly where, within a page, the GOT entry will be in
the target address space.

Fixes <rdar://problem/18693976>.

llvm-svn: 220347

llvm-svn: 220346

Summary: Patches 202051 and 208013 added calls to LTO's PassManager which unconditionally add LoopVectorizePass and SLPVectorizerPass instead of following the logic in PassManagerBuilder::populateModulePassManager and honoring the -vectorize-loops -run-slp-after-loop-vectorization flags.

Reviewers: nadav, aschwaighofer, yijiang

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5884

llvm-svn: 220345

llvm-svn: 220344

complete object to a pointer to the start of another complete object does
not evaluate to the constant 'false'. All other comparisons between the
addresses of subobjects of distinct complete objects still do.

llvm-svn: 220343

llvm-svn: 220342

These are named following the IEEE-754 names for these
functions, rather than the libm fmin / fmax to avoid
possible ambiguities. Some languages may implement something
resembling fmin / fmax which return NaN if either operand is
to propagate errors. These implement the IEEE-754 semantics
of returning the other operand if either is a NaN representing
missing data.

llvm-svn: 220341

Enumerate `MDNode`'s operands *before* the node itself, so that the
reader requires less RAUW.  Although this will cause different code
paths to be hit in the reader, this should effectively be no
functionality change.

llvm-svn: 220340

llvm-svn: 220339

llvm-svn: 220338

No one cares how many uses each metadata value has, so don't bother
counting.

llvm-svn: 220337

This matches the behavior of GNU ar and also makes it easier to implemnt
support for the addlib command.

llvm-svn: 220336

llvm-svn: 220335