Started 12 mo ago
Took 4 hr 18 min on green-dragon-02

Failed Build #14810 (Oct 1, 2019 8:02:38 PM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 373420
  • http://llvm.org/svn/llvm-project/cfe/trunk : 373421
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 373405
  • http://llvm.org/svn/llvm-project/zorg/trunk : 373227
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 373402
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 373392
Changes
  1. Revert r368237 - Update fix-it hints for std::move warnings.

    r368237 attempted to improve fix-its for move warnings, but introduced some
    regressions to -Wpessimizing-move.  Revert that change and add the missing
    test cases to the pessimizing move test to prevent future regressions. (detail)
    by rtrieu
  2. DebugInfo: Update support for detecting C++ language variants in debug info emission (detail)
    by dblaikie
  3. gn build: (manually) merge r373407 (detail)
    by nico
  4. Fix crash on constant-evaluation of pseudo-destruction of a pointer.

    We got confused and thought we might be pseudo-destroying the pointee
    instead. (detail)
    by rsmith
  5. AMDGPU/GlobalISel: Use getIntrinsicID helper (detail)
    by arsenm
  6. Remove TypeNodes.def from the modulemap.

    We currently just look for files named in the modulemap in its
    associated source directory.  This means that we can't name
    generated files, like TypeNodes.def now is, which means we can't
    explicitly mark it as textual.  But fortunately that's okay
    because (as I understand it) the most important purpose of naming
    the header in the modulemap is to ensure that it's not treated as
    public, and the search for public headers also only considers
    files in the associated source directory.  This isn't an elegant
    solution, since among other things it means that a build which
    wrote the generated files directly into the source directory would
    result in something that wouldn't build as a module, but that's
    a problem for all our other generated files as well. (detail)
    by rjmccall
  7. AMDGPU/GlobalISel: Assume VGPR for G_FRAME_INDEX

    In principle this should behave as any other constant. However
    eliminateFrameIndex currently assumes a VALU use and uses a vector
    shift. Work around this by selecting to VGPR for now until
    eliminateFrameIndex is fixed. (detail)
    by arsenm
  8. AMDGPU/GlobalISel: Private loads always use VGPRs (detail)
    by arsenm
  9. AMDGPU/GlobalISel: Legalize 1024-bit G_BUILD_VECTOR

    This will be needed to support AGPR operations. (detail)
    by arsenm
  10. AMDGPU/GlobalISel: Fix RegBankSelect for 1024-bit values (detail)
    by arsenm
  11. [AMDGPU] separate accounting for agprs

    Account and report agprs separately on gfx908. Other targets
    do not change the reporting.

    Differential Revision: https://reviews.llvm.org/D68307 (detail)
    by rampitec
  12. Fix unused variable warning. NFCI. (detail)
    by hliao
  13. [X86] Add a DAG combine to shrink vXi64 gather/scatter indices that are constant with sufficient sign bits to fit in vXi32

    The gather/scatter instructions can implicitly sign extend the indices. If we're operating on 32-bit data, an v16i64 index can force a v16i32 gather to be split in two since the index needs 2 registers. If we can shrink the index to the i32 we can avoid the split. It should always be safe to shrink the index regardless of the number of elements. We have gather/scatter instructions that can use v2i32 index stored in a v4i32 register with v2i64 data size.

    I've limited this to before legalize types to avoid creating a v2i32 after type legalization. We could check for it, but we'd also need testing. I'm also only handling build_vectors with no bitcasts to be sure the truncate will constant fold.

    Differential Revision: https://reviews.llvm.org/D68247 (detail)
    by ctopper
  14. Emit TypeNodes.def with tblgen.

    The primary goal here is to make the type node hierarchy available to
    other tblgen backends, although it should also make it easier to generate
    more selective x-macros in the future.

    Because tblgen doesn't seem to allow backends to preserve the source
    order of defs, this is not NFC because it significantly re-orders IDs.
    I've fixed the one (fortunately obvious) place where we relied on
    the old order.  Unfortunately, I wasn't able to share code with the
    existing AST-node x-macro generators because the x-macro schema we use
    for types is different in a number of ways.  The main loss is that
    subclasses aren't ordered together, which doesn't seem important for
    types because the hierarchy is generally very shallow with little
    clustering. (detail)
    by rjmccall
  15. Use scope qualifiers in Clang's tblgen backends to get useful
    redeclaration checking.  NFC. (detail)
    by rjmccall
  16. [CMake] Fix the value of `config.target_cflags` for non-macOS Apple platforms. Attempt #3.

    The main problem here is that `-*-version_min=` was not being passed to
    the compiler when building test cases. This can cause problems when
    testing on devices running older OSs because Clang would previously
    assume the minimum deployment target is the the latest OS in the SDK
    which could be much newer than what the device is running.

    Previously the generated value looked like this:

    `-arch arm64 -isysroot
    <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`

    With this change it now looks like:

    `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot
    <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`

    This mirrors the setting of config.target_cflags on macOS.

    This change is made for ASan, LibFuzzer, TSan, and UBSan.

    To implement this a new `get_test_cflags_for_apple_platform()` function
    has been added that when given an Apple platform name and architecture
    returns a string containing the C compiler flags to use when building
    tests. This also calls a new helper function `is_valid_apple_platform()`
    that validates Apple platform names.

    This is the third attempt at landing the patch.

    The first attempt (r359305) had to be reverted (r359327) due to a buildbot
    failure. The problem was that calling `get_test_cflags_for_apple_platform()`
    can trigger a CMake error if the provided architecture is not supported by the
    current CMake configuration. Previously, this could be triggered by passing
    `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were
    generating test configurations for a list of architectures without checking if
    the relevant Sanitizer actually supported that architecture. We now intersect
    the list of architectures for an Apple platform with
    `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer name) to
    iterate through the correct list of architectures.

    The second attempt (r363633) had to be reverted (r363779) due to a build
    failure. The failed build was using a modified Apple toolchain where the iOS
    simulator SDK was missing. This exposed a bug in the existing UBSan test
    generation code where it was assumed that `COMPILER_RT_ENABLE_IOS` implied that
    the toolchain supported both iOS and the iOS simulator. This is not true. This
    has been fixed by using the list `SANITIZER_COMMON_SUPPORTED_OS` for the list
    of supported Apple platforms for UBSan. For consistency with the other
    Sanitizers we also now intersect the list of architectures with
    UBSAN_SUPPORTED_ARCH.

    rdar://problem/50124489

    Differential Revision: https://reviews.llvm.org/D61242 (detail)
    by Dan Liew
  17. AMDGPU: Fix an out of date assert in addressing FrameIndex

    Reviewers:
      arsenm

    Differential Revision:
      https://reviews.llvm.org/D67574 (detail)
    by chfang
  18. [libFuzzer] Remove lazy counters.

    Summary: Lazy counters haven't improved performance for large fuzz targets.

    Reviewers: kcc

    Reviewed By: kcc

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D67476 (detail)
    by morehouse

Started by timer (4 times)

This run spent:

  • 3 hr 51 min waiting;
  • 4 hr 18 min build duration;
  • 8 hr 10 min total from scheduled to completion.

Identified problems

Compile Error

This build failed because of a compile error. Below is a list of all errors in the build log:
Indication 1

Ninja target failed

Below is a link to the first failed ninja target.
Indication 2

Regression test failed

This build failed because a regression test in the test suite FAILed. See the test report for details.
Indication 3

Missing test results

The test result file Jenkins is looking for does not exist after the build.
Indication 4

Assertion failure

This build failed because of an assertion failure. Below is a list of all errors in the build log:
Indication 5