This is a follow-up to r199260. On ARM hosts, we were attempting to run
tests with triples such as armv7l-unknown-win32. This expands that fix to
cover all non-x86 targets since we only support MS ABI on x86.

llvm-svn: 199280

llvm-svn: 199279

llvm-svn: 199278

llvm-svn: 199277

presence of CU ranges.

llvm-svn: 199276

llvm-svn: 199275

llvm-svn: 199274

Fixes dynamically linked programs on NetBSD/i386.

llvm-svn: 199273

llvm-svn: 199269

llvm-svn: 199268

llvm-svn: 199267

The changes caused by folding an sp-adjustment into a "pop" previously
disrupted the forward search for the final real instruction in a
terminating block. This switches to a backward search (skipping debug
instrs).

This fixes PR18399.

Patch by Zhaoshi.

llvm-svn: 199266

We should set them to expand for now since there are no patterns
dealing with them. Actually, there are no instructions either so I
doubt they'll ever be acceptable.

llvm-svn: 199265

to run lld tests individually.

llvm-svn: 199264

-ffunction-sections and update comments and TODOs about other
places that we should enable this.

llvm-svn: 199263

llvm-svn: 199262

MCJIT remote execution (ChildTarget+RemoteTargetExternal) protocol was in
dire need of refactoring. It was fail-prone, had no error reporting and
implemented the same message logic on every single function.

This patch rectifies it, and makes it work on ARM, where it was randomly
failing. Other architectures shall profit from this change as well, making
their buildbots and releases more reliable.

llvm-svn: 199261

Long term we should make -triple arm7l-*-win32 do something sensible,
but for now it's broken and untested.

llvm-svn: 199260

llvm-svn: 199259

llvm-svn: 199258

llvm-svn: 199257

Someone recently wasted some time not realising that "-###" didn't
actually execute the commands it printed, and suggested a
documentation tweak.

Having made the same mistake myself on at least one occasion, I
sympathise. So here it is. Any kibitzing on an even better text
welcome.

llvm-svn: 199256

-Wselector detects an unimplemented method used
in an @selector expression. // rdar://15781538

llvm-svn: 199255

llvm-svn: 199254

Bitcasts can't be between address spaces anymore.

llvm-svn: 199253

promotion code, Tablegen will now select FPExt for floating point promotions
(previously it had returned AExt, which is not valid for floating point types).

Any out-of-tree targets that were relying on AExt being returned for FP
promotions will need to update their code check for FPExt instead.

llvm-svn: 199252

llvm-svn: 199251

This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.

To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.

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

llvm-svn: 199250

These functions have the same constness properties of the normal libm
functions, which allows LLVM to optimise code better in general. There
are also a couple of specific optimisations that only trigger when
these are properly marked.

rdar://problem/13729466

llvm-svn: 199249

This reverts commit r199242.

It is causing CodeGen/AArch64/neon-bsl.ll to fail.

llvm-svn: 199248

Better describe the flag that enables drop-in MSVC compatibility, including
ability to parse MS standard headers. This is intended to distinguish it from
-fms-extensions, the more established and 'gentler' flag also supported by GCC.

The new wording matches up with the internal description introduced in r198936.
Still room for improvement (e.g. C++ is part of the product name, yet the flag
also applies to C) but it's a step forward from "Microsoft mode".

llvm-svn: 199247

llvm-svn: 199246

This also fixes the placement of the function label comment. It was being
placed next to the mips16 directive instead of next to the label.

llvm-svn: 199245

Reapply r199191, reverted in r199197 because it carelessly broke
Other/link-opts.ll.  The problem was that calling
createInternalizePass("main") would select
createInternalizePass(bool("main")) instead of
createInternalizePass(ArrayRef<const char *>("main")).  This commit
fixes the bug.

The original commit message follows.

Add API to LTOCodeGenerator to specify a strategy for the -internalize
pass.

This is a new attempt at Bill's change in r185882, which he reverted in
r188029 due to problems with the gold linker.  This puts the onus on the
linker to decide whether (and what) to internalize.

In particular, running internalize before outputting an object file may
change a 'weak' symbol into an internal one, even though that symbol
could be needed by an external object file --- e.g., with arclite.

This patch enables three strategies:

- LTO_INTERNALIZE_FULL: the default (and the old behaviour).
- LTO_INTERNALIZE_NONE: skip -internalize.
- LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden
  visibility.

LTO_INTERNALIZE_FULL should be used when linking an executable.

Outputting an object file (e.g., via ld -r) is more complicated, and
depends on whether hidden symbols should be internalized.  E.g., for
ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and
LTO_INTERNALIZE_HIDDEN can be used otherwise.  However,
LTO_INTERNALIZE_FULL is inappropriate, since the output object file will
eventually need to link with others.

lto_codegen_set_internalize_strategy() sets the strategy for subsequent
calls to lto_codegen_write_merged_modules() and lto_codegen_compile*().

<rdar://problem/14334895>

llvm-svn: 199244

llvm-svn: 199243

llvm-svn: 199242

llvm-svn: 199241

llvm-svn: 199240

llvm-svn: 199239

symbols in case of executable file linking.

llvm-svn: 199238