llvm-svn: 289519

llvm-svn: 289518

Summary:
This pass will be used to relax instructions which use out of bounds
memory accesses to equivalent operations that can work with the
addresses.

The pass currently implements relaxation for the STDWPtrQRr instruction.

Without this pass, an assertion error would be hit in the pseudo expansion pass.

In the future, we will need to add more instructions to this pass. We can do
that on a case-by-case basic.

Reviewers: arsenm, kparzysz

Subscribers: wdng, llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D27650

llvm-svn: 289517

llvm-svn: 289516

llvm-svn: 289515

  lib/CodeGen/CGExpr.cpp:2511:2: warning: extra ';' [-Wpedantic]
   };
    ^

Clean up warning from gcc 6.

llvm-svn: 289514

The macOS thread-local variable finalizer routines do not handle the
case where a termination function registers another termination function
correctly, causing this test to fail. I've filed a radar for this;
mark the test XFAIL in the meantime. See [1] for more details.

[1] http://lists.llvm.org/pipermail/cfe-dev/2016-November/051376.html

Differential Revision: https://reviews.llvm.org/D27434

llvm-svn: 289513

After r289363, these tests were triggering MSVC x64 warning C4267
"conversion from 'size_t' to 'int', possible loss of data" by taking 0, 2, and 10
as std::size_t, then constructing error_code(int, const error_category&) or
error_condition(int, const error_category&) from that (N4618 19.5.3.2
[syserr.errcode.constructors]/3, 19.5.4.2 [syserr.errcondition.constructors]/3).

The fix is simple: take these ints as int, pass them to the int-taking
constructor, and perform a value-preserving static_cast<std::size_t>
when comparing them to `std::size_t result`.

Fixes D27691.

llvm-svn: 289512

Summary: Split out formatting and style changes from D26061

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D26691

llvm-svn: 289511

The general idea here is to get enough of the existing restrictions out of the way that the already existing folding logic in foldMemoryOperand can kick in for STATEPOINTs and fold references to immutable stack slots. The key changes are:

    Support for folding multiple operands at once which reference the same load
    Support for folding multiple loads into a single instruction
    Walk all the operands of the instruction for varidic instructions (this is a bug fix!)

Once this lands, I'll post another patch which refactors the TII interface here. There's nothing actually x86 specific about the x86 code used here.

Differential Revision: https://reviews.llvm.org/D24103

llvm-svn: 289510

The stack slot reuse code had a really amusing bug. We ended up only reusing a stack slot exact once (initial use + reuse) within a basic block. If we had a third statepoint to process, we ended up allocating a new set of stack slots. If we crossed a basic block boundary, the set got cleared. As a result, code which is invoke heavy doesn't see the problem, but multiple calls within a basic block does. Net result: as we optimize invokes into calls, lowering gets worse.

The root error here is that the bitmap uses by the custom allocator wasn't kept in sync. The result was that we ended up resizing the bitmap on the next statepoint (to handle the cross block case), reset the bit once, but then never reset it again.

Differential Revision: https://reviews.llvm.org/D25243

llvm-svn: 289509

llvm-svn: 289508

fatal error: error in backend: Global variable '__sancov_gen_' has an
invalid section specifier '__sancov_guards': mach-o section specifier
requires a segment and section separated by a comma.

llvm-svn: 289507

[libFuzzer] don't require extra flags with -minimize_crash=1 (default to -max_total_time=600). Also respect exact_artifact_path when outputting the end result

llvm-svn: 289506

llvm-svn: 289505

llvm-svn: 289504

Turns out if you were on windows and your default target wasn't windows the system-windows feature wasn't getting enabled.

This fixes that and updates the coff-dwarf test to rely on the new "target-windows" feature. That test was the reason why system-windows was changed to not always be enabled on Windows hosts.

llvm-svn: 289503

This reverts commit r249937.

llvm-svn: 289502

Summary:
This should improve the error messages generated providing a bit more
information when the failures are printed out. One example of a
contrived error looks like:

```
Expected: (Buffers.getBuffer(Buf)) != (std::error_code()), actual:
system:0 vs system:0
```

Because we're using error codes, the default printing gets us more
useful information in case of failure.

This is a follow-up on D26232.

Reviewers: rSerge

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D27495

llvm-svn: 289501

llvm-svn: 289499

Subscribers: kubabrecka, mgorny

Differential Revision: https://reviews.llvm.org/D26758

llvm-svn: 289498

Hopefully this will fix the failing Windows bot.

llvm-svn: 289497

These extra specializations were added in the depths of history (r67984 from
2009) and are clearly problematic now. The pointers actually are aligned to the
default (8 bytes), since otherwise UBsan would be complaining loudly.

I *think* it originally made sense because there was no "alignof" to infer the
correct value so the generic case went with what malloc returned (8-byte
aliged objects), and on 32-bit machines this specialization was correct. It
became wrong when we started compiling for 64-bit, and caused a UBSan failure
when we tried to put a ValueHandle into a DenseMap.

Should fix the Green Dragon UBSan bot.

llvm-svn: 289496

Implemented timeouts for Windows using TimerQueueTimers.
Timers are used to supervise the time of execution of the
callback function that is being fuzzed.

Differential Revision: https://reviews.llvm.org/D27237

llvm-svn: 289495

Reverts commit r289478.

This broke
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/2070
(and maybe
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules-2/builds/2246)

llvm-svn: 289494

llvm-svn: 289493

llvm-svn: 289492

This change enables building builtins for multiple different targets
using LLVM runtimes directory.

To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS
variable, where the value is the list of targets.  To pass a per target
variable to the builtin build, you can set BUILTINS_<target>_<variable>
where <variable> will be passed to the builtin build for <target>.

Differential Revision: https://reviews.llvm.org/D26652

llvm-svn: 289491

This reverts commit r260386.

These tests all pass for me locally. I have no idea if they will pass on all configurations, so I'll watch the bots closely.

llvm-svn: 289490

This is used when building builtins for multiple targets as part
of LLVM runtimes.

Differential Revision: https://reviews.llvm.org/D26653

llvm-svn: 289489

incorrect output when LLVM is built with `LLVM_BUILD_LLVM_DYLIB`.

`llvm-config` previously produced output like this

```
$ llvm-config --libfiles
/usr/lib/liblibLLVM-4.0svn.so.so
$ llvm-config --libnames
liblibLLVM-4.0svn.so.so
```

The library prefix and shared library extension were added to
the library name twice which was wrong.

I wanted to write a test cases for this but it looks like **all**
`llvm-config` tests were disabled by r260386 so I'll leave this for
now.

Subscribers: llvm-commits, tstellarAMD

Reviewers: beanz, DiamondLovesYou, axw

Differential Revision: https://reviews.llvm.org/D27393

llvm-svn: 289488

Reverts r289181: it's currently breaking modules using simd.h in
10.12 SDK.

This reverts commit 6e73e3464e96a4e00492c24aa790d36e1adb5702.

llvm-svn: 289487

Differential Revision: https://reviews.llvm.org/D27582

llvm-svn: 289486

Thanks dblaikie!

llvm-svn: 289485

This test is (I think) actually trying to make sure no errors are printed, but it hits on the string "error" in flags.

llvm-svn: 289484

This reverts commit r260281.

llvm-svn: 289483

This reverts r289215 (git SHA1 cb7b86a1).  It breaks the ubsan build
because a DenseMap that keys off of `AssertingVH<T>` will hit UB when it
tries to cast the empty and tombstone keys to `T *` (due to insufficient
alignment).

This is the relevant stack trace (thanks to Mike Aizatsky):

    #0 0x25cf100 in llvm::AssertingVH<llvm::PHINode>::getValPtr() const llvm/include/llvm/IR/ValueHandle.h:212:39
    #1 0x25cea20 in llvm::AssertingVH<llvm::PHINode>::operator=(llvm::AssertingVH<llvm::PHINode> const&) llvm/include/llvm/IR/ValueHandle.h:234:19
    #2 0x25d0092 in llvm::DenseMapBase<llvm::DenseMap<llvm::AssertingVH<llvm::PHINode>, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::AssertingVH<llvm::PHINode> >, llvm::detail::DenseSetPair<llvm::AssertingVH<llvm::PHINode> > >, llvm::AssertingVH<llvm::PHINode>, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo<llvm::AssertingVH<llvm::PHINode> >, llvm::detail::DenseSetPair<llvm::AssertingVH<llvm::PHINode> > >::clear() llvm/include/llvm/ADT/DenseMap.h:113:23

llvm-svn: 289482

llvm-svn: 289481

llvm-svn: 289480

I'm transitioning away from my current employer, and I do not foresee myself
spending much time on LLDB in the near future. Ideally somebody on the Google
Android team takes over the gdb-remote protocol tests, and somebody with decent
familiarity with the test suite infrastructure takes over the parallel test
runner and test event stream portions of the Python test suite.

llvm-svn: 289479