llvm-svn: 316955

llvm-svn: 316954

It's not guaranteed. There's a bug open to sort them in predecessor
order, but it won't happen anytime soon. In the meanwhile, passes
will have to do an O(#preds) scan. Such is life.

llvm-svn: 316953

Revert r316478.
A test case has failed.
Will recommit this change once we find and fix the failure.

This reverts commit 7c330fabaedaba3d02c58bc3cc1198896c895f34.

llvm-svn: 316952

Add more fuzzing bits: partial_sort_copy, partition_copy, unique, unique_copy. No functional change to libc++; this is all test infastructure

llvm-svn: 316951

Summary:
For reference, see: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116589.html

This patch fleshes out the instruction class hierarchy with respect to atomic and
non-atomic memory intrinsics. With this change, the relevant part of the class
hierarchy becomes:

IntrinsicInst
  -> MemIntrinsicBase (methods-only class)
    -> MemIntrinsic (non-atomic intrinsics)
      -> MemSetInst
      -> MemTransferInst
        -> MemCpyInst
        -> MemMoveInst
    -> AtomicMemIntrinsic (atomic intrinsics)
      -> AtomicMemSetInst
      -> AtomicMemTransferInst
        -> AtomicMemCpyInst
        -> AtomicMemMoveInst
    -> AnyMemIntrinsic (both atomicities)
      -> AnyMemSetInst
      -> AnyMemTransferInst
        -> AnyMemCpyInst
        -> AnyMemMoveInst

This involves some class renaming:
    ElementUnorderedAtomicMemCpyInst -> AtomicMemCpyInst
    ElementUnorderedAtomicMemMoveInst -> AtomicMemMoveInst
    ElementUnorderedAtomicMemSetInst -> AtomicMemSetInst
A script for doing this renaming in downstream trees is included below.

An example of where the Any* classes should be used in LLVM is when reasoning
about the effects of an instruction (ex: aliasing).

---
Script for renaming AtomicMem* classes:
PREFIXES="[<,([:space:]]"
CLASSES="MemIntrinsic|MemTransferInst|MemSetInst|MemMoveInst|MemCpyInst"
SUFFIXES="[;)>,[:space:]]"

REGEX="(${PREFIXES})ElementUnorderedAtomic(${CLASSES})(${SUFFIXES})"
REGEX2="visitElementUnorderedAtomic(${CLASSES})"

FILES=$( grep -E "(${REGEX}|${REGEX2})" -r . | tr ':' ' ' | awk '{print $1}' | sort | uniq )

SED_SCRIPT="s~${REGEX}~\1Atomic\2\3~g"
SED_SCRIPT2="s~${REGEX2}~visitAtomic\1~g"

for f in $FILES; do
    echo "Processing: $f"
    sed  -i ".bak" -E "${SED_SCRIPT};${SED_SCRIPT2};${EA_SED_SCRIPT};${EA_SED_SCRIPT2}" $f
done

Reviewers: sanjoy, deadalnix, apilipenko, anna, skatkov, mkazantsev

Reviewed By: sanjoy

Subscribers: hfinkel, jholewinski, arsenm, sdardis, nhaehnle, JDevlieghere, javed.absar, llvm-commits

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

llvm-svn: 316950

Summary: This fixes failure in Transforms/GVNHoist/hoist.ll uncovered by D39245.

Reviewers: hiraditya, spop, dberlin

Reviewed By: dberlin

Subscribers: llvm-commits

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

llvm-svn: 316949

Storing diffs.txt is now redundant, as we simply dump the CmpRuns output
to stdout (it is saved in CI and tends to be small).
Not generating those files enables us to remove empty folders, which
confuse git, as it would not add them with reference results.

llvm-svn: 316948

llvm-svn: 316947

These cases will be addressed in a future update to D39126.

llvm-svn: 316946

llvm-svn: 316945

llvm-svn: 316944

Summary: Fixes https://reviews.llvm.org/D39072

Reviewers: cryptoad

Reviewed By: cryptoad

Subscribers: kubamracek

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

llvm-svn: 316943

This matches the original libunwind API. This also unifies the
type between ARM EHABI and the other configurations, and allows
getting rid of a number of casts in log messages.

The cursor size updates for ppc and or1k are untested, but
unw_proc_info_t shrinks by 4 uint64_t units on i386 at least.

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

llvm-svn: 316942

LWG 3013 points out that the constructors and increment members
of the directory iterators need to allocate, and therefore cannot
be marked noexcept.

It also points out that `is_empty` and `copy` likely need to allocate
as well, and as such can also not be noexcept.

This patch speculatively implements the resolution removing noexcept,
because libc++ does indeed have the possibility of throwing on allocation
failure.

llvm-svn: 316941

llvm-svn: 316940

The guts of the increment method for recursive_directory_iterator
was failing to pass an error code object to calls to status/symlink_status,
which can throw under certain conditions.

This patch fixes the issues by correctly propagating the error codes.
However the noexcept still needs to be removed from the signature, as
mentioned in LWG 3014, but that change will be made in a separate commit.

llvm-svn: 316939

llvm-svn: 316938

Summary: This should fix the Windows bots after D39072.

Reviewers: alekseyshl, flowerhack

Reviewed By: flowerhack

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 316937

llvm-svn: 316936

Add a test to make sure that -Wdeprecated doesn't warn on use of 'throw()' in system headers (deprecated in C++17).

llvm-svn: 316935

Summary:
Fixed version of https://reviews.llvm.org/D38437 (fixes Win/Fuchsia failures).

Creating a new revision, since the old one was getting a bit old/crowded.

    In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
    VMAR, which means that MmapNoAccess can only be called once. This works
    for the sanitizer allocator but *not* for the Scudo allocator.
    
    Hence, this changeset introduces a new ReservedAddressRange object to
    serve as the new API for these calls. In this changeset, the object
    still calls into the old Mmap implementations.
    
    The next changeset two changesets will convert the sanitizer and scudo
    allocators to use the new APIs, respectively. (ReservedAddressRange will
    replace the SecondaryHeader in Scudo.)
    
    Finally, a last changeset will update the Fuchsia implementation.


Reviewers: alekseyshl, cryptoad, phosek

Reviewed By: alekseyshl, cryptoad

Subscribers: kubamracek

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

llvm-svn: 316934

llvm-svn: 316933

llvm-svn: 316932

We might want to drop support for such large symbols, but that should
be an explicit decision with a testcase.

llvm-svn: 316931

There are two instances of -Wcast-qual and one of -Wsign-compare.

llvm-svn: 316930

Users have requested that we add it to the list:
https://github.com/google/sanitizers/issues/864

llvm-svn: 316929

Since we now only check st_value, we have to consider the case where
the section index is special.

llvm-svn: 316928

llvm-svn: 316927

llvm-svn: 316926

llvm-svn: 316925

The analyzer did not return an UndefVal in case a negative value was left
shifted. I also altered the UndefResultChecker to emit a clear warning in this
case.

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

llvm-svn: 316924

llvm-svn: 316922

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

Change-Id: I71c8605a8e4c98013ef25289694afc5cfd46bb0b
llvm-svn: 316921

llvm-svn: 316920

I accidentally left a linux-specific include in generic code.

llvm-svn: 316919

llvm-svn: 316917

Summary: The two 32-bit words were swapped. Update a test omitted in reverted r316270.

Reviewers: jtony, aaron.ballman

Subscribers: nemanjai, kbarton

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

llvm-svn: 316916

Versions of android before kitkat implemented pselect non-atomically,
which caused flakyness, as we were relying on it atomically setting the
signal mask to implement waiting for signals.

This patch implements a direct call to the the pselect kernel syscall,
which does not suffer from this problem. The code itself is not very
pretty, but fortunately the uglyness is contained in the
android version of the MainLoop::RunImpl::Poll function.

llvm-svn: 316915

Fix PR#35119 : set_union misbehaves with move_iterators. Thanks to Denis Yaroshevskiy for both the bug report and the fix.

llvm-svn: 316914