llvm-svn: 316971

llvm-svn: 316970

llvm-svn: 316969

These files shouldn't have been submitted in 316967

llvm-svn: 316968

Issue found by llvm-isel-fuzzer on OSS fuzz, https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3725

If anyone actually cares about > 64 bit arithmetic, there's a lot more to do in this area.  There's a bunch of obviously wrong code in the same function.  I don't have the time to fix all of them and am just using this to understand what the workflow for fixing fuzzer cases might look like.

llvm-svn: 316967

rdar://35172419

llvm-svn: 316966

They might have different visibility, and thus discarding all but one of them
can result in rejecting valid code. Also fix name lookup to cope with multiple
using-directives being found that denote the same namespace, where some are not
visible -- don't cache an "already visited" state for a using-directive that we
didn't visit because it was hidden.

llvm-svn: 316965

llvm-svn: 316964

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

llvm-svn: 316963

We don't need to extend/truncate the Known structure before calling computeKnownBits - it will reset at the start of the function.

llvm-svn: 316962

All SHT_NOTE sections should have minimum alignment 4.

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

llvm-svn: 316961

llvm-svn: 316960

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

llvm-svn: 316959

check_cxx_compiler_flag doesn't seem to try to link a program, so
the existing code doesn't correctly detect the availability of a given
linker.  This patch uses check_cxx_source_compiles instead.

I confirmed that cmake now reports this error

  Host compiler does not support '-fuse-ld=foo'

for -DLLVM_USE_LINKER=foo.

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

llvm-svn: 316958

InferAddressSpaces assumes the pointee type of addrspacecast
is the same as the operand, which is not always true and causes
invalid IR.

This bug cause build failure in HCC.

This patch fixes that.

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

llvm-svn: 316957

Fix linker not being correctly detected when a custom one is specified
through LLVM_USE_LINKER CMake variable.

In particular,

  cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold ../llvm

resulted into

  Linker detection: GNU ld

instead of

  Linker detection: GNU Gold

due to the construction not accounting for such variable. It led to the general
confusion and prevented setting linker-specific flags inside functions defined
in AddLLVM.cmake.

Thanks Oleksii Vilchanskyi for the patch!

llvm-svn: 316956

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