Started 5 days 23 hr ago
Took 5 hr 9 min on green-dragon-02

Failed Build #14240 (Jun 19, 2019 6:17:27 AM)

  • : 363797
  • : 363794
  • : 363779
  • : 363785
  • : 363764
  • : 363798
  1. [clangd] Correct the MessageType enum values. (detail)
    by hokein
  2. Revert rL363678 : AMDGPU: Add ds_gws_init / ds_gws_barrier intrinsics

    There may or may not be additional work to handle this correctly on
    Breaks EXPENSIVE_CHECKS buildbots - (detail)
    by rksimon
  3. [NFC] Added tests for D63534 (detail)
    by xbolva00
  4. [NFC] Added tests for cttz(abs(x)) -> cttz(x) fold (detail)
    by xbolva00
  5. [OpenCL] Split type and macro definitions into opencl-c-base.h

    Using the -fdeclare-opencl-builtins option will require a way to
    predefine types and macros such as `int4`, `CLK_GLOBAL_MEM_FENCE`,
    etc.  Move these out of opencl-c.h into opencl-c-base.h such that the
    latter can be shared by -fdeclare-opencl-builtins and

    This changes the behaviour of -finclude-default-header when
    -fdeclare-opencl-builtins is specified: instead of including the full
    header, it will include the header with only the base definitions.

    Differential revision: (detail)
    by svenvh
  6. [DAGCombiner] Support (shl (ext (shl x, c1)), c2) -> (shl (ext x), (add c1, c2)) non-uniform folds.

    Use matchBinaryPredicate instead of isConstOrConstSplat to let us handle non-uniform shift cases. (detail)
    by rksimon
  7. [DAGCombiner] Support (shl (ext (shl x, c1)), c2) -> 0 non-uniform folds.

    Use matchBinaryPredicate instead of isConstOrConstSplat to let us handle non-uniform shift cases.

    This requires us to tweak matchBinaryPredicate to allow it to (optionally) handle constants with different type widths. (detail)
    by rksimon
  8. [X86] Add non-uniform (shl (ext (shl x, c1)), c2) -> (shl (ext x), (add c1, c2)) test (detail)
    by rksimon
  9. Revert r363116 "[X86] [ABI] Fix i386 ABI "__m64" type bug"

    This introduced MMX instructions in code that wasn't previously using
    them, breaking programs using 64-bit vectors and x87 floating-point in
    the same application. See discussion on the code review for more

    > According to System V i386 ABI: the  __m64 type paramater and return
    > value are passed by MMX registers. But current implementation treats
    > __m64 as i64 which results in parameter passing by stack and returning
    > by EDX and EAX.
    > This patch fixes the bug (
    > for Linux and NetBSD.
    > Patch by Wei Xiao (wxiao3)
    > Differential Revision: (detail)
    by hans
  10. [DAGCombiner] visitSHL - pull out repeated shift amount VT. NFCI. (detail)
    by rksimon
  11. [analyzer][NFC][tests] Pre-normalize expected-sarif files

    As discussed in the review for D62952, this patch pre-normalizes the
    reference expected output sarif files by removing lines containing
    fields for which we expect differences that should be ignored. (detail)
    by hubert.reinterpretcast
  12. [DAGCombine] Fix (shl (ext (shl x, c1)), c2) -> (shl (ext x), (add c1, c2)) comment. NFCI.

    We pre-extend, not post. (detail)
    by rksimon
  13. [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion


    The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here:

    A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins.
    B) Instructions in the middle block have different line numbers which give the impression of another iteration.

    In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks.

    I have set up a separate review D61933 for a fix which is required for this patch.

    Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse

    Reviewed By: hfinkel, jmorse

    Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits

    Tags: #llvm, #debug-info

    Differential Revision:

    llvm-svn: 363046 (detail)
    by orlandoch
  14. [zorg] Add solaris11-amd64, solaris11-sparcv9 builders

    I'm working to provide two Solaris 11.4 build slaves with a clang builder
    each, one on amd64, the other on sparcv9.  I'm still working out the
    details like parallelism and max_builds, but the attached patch captures
    the basics, intended to be minimal.

    Differential Revision: (detail)
    by ro
  15. [ConstantFolding] Fix assertion failure on non-power-of-two vector load.

    The test case does an (out of bounds) load from a global constant with
    type <3 x float>. InstSimplify tried to turn this into an integer load
    of the whole alloc size of the vector, which is 128 bits due to
    alignment padding, and then bitcast this to <3 x vector> which failed
    an assertion due to the type size mismatch.

    The fix is to do an integer load of the normal size of the vector, with
    no alignment padding.

    Reviewers: tpr, arsenm, majnemer, dstuttard

    Reviewed By: arsenm

    Subscribers: hfinkel, wdng, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by foad
  16. [RISCV] Allow parsing immediates that use tilde & exclaim

    This patch allows immediates (and CSR alias immediates) which start with
    a tilde token or an exclaim (!) token to be parsed as intended.

    Differential Revision: (detail)
    by lewis-revill
  17. [RISCV] Fix failure to parse parenthesized immediates

    Since the parser attempts to parse an operand as a register with
    parentheses before parsing it as an immediate, immediates in
    parentheses should not be parsed by parseRegister. However in the case
    where the immediate does not start with an identifier, the LParen is not
    unlexed and so the RParen causes an unexpected token error.

    This patch adds the missing UnLex, and modifies the existing UnLex to
    not use a buffered token, as it should always be unlexing an LParen.

    Differential Revision: (detail)
    by lewis-revill
  18. Fix r363773: Update Barcelona MCA tests. (detail)
    by courbet
  19. Make TargetParserTest.ARMExtensionFeatures not run out of memory on 32-bit (PR42316)

    The test still probably shouldn't run this loop 17 million times, but at
    least now it won't run out of memory. (detail)
    by hans
  20. Revert r363633 "[CMake] Fix the value of `config.target_cflags` for non-macOS Apple platforms. Attempt #2."

    This caused Chromium's clang package to stop building, see comment on for details.

    > Summary:
    > 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 second 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.
    > rdar://problem/50124489
    > Reviewers: kubamracek, yln, vsk, juliehockett, phosek
    > Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits
    > Tags: #llvm, #sanitizers
    > Differential Revision: (detail)
    by hans
  21. [Sanitizers] Fix compilation on Solaris 11.5

    A recent build of Solaris 11.5 Beta (st_047) gained madvise(MADV_DONTDUMP)
    support for Linux compatibility.  This broke the compiler-rt build:

      /vol/llvm/src/llvm/dist/projects/compiler-rt/lib/sanitizer_comm/ In function ‘bool __sanitizer::DontDumpShadowMemory(__sanitizer::uptr, __sanitizer::uptr)’:
      /vol/llvm/src/llvm/dist/projects/compiler-rt/lib/sanitizer_common/ error: invalid conversion from ‘void*’ to ‘caddr_t’ {aka ‘char*’} [-fpermissive]
         81 |   return madvise((void *)addr, length, MADV_DONTDUMP) == 0;
            |                  ^~~~~~~~~~~~
            |                  |
            |                  void*
      In file included from
      /usr/include/sys/mman.h:231:20: note: initializing argument 1 of ‘int
    madvise(caddr_t, std::size_t, int)’
        231 | extern int madvise(caddr_t, size_t, int);
            |                    ^~~~~~~

    The obvious fix is to use the same solution that has already been used a
    couple of lines earlier:

      // In the default Solaris compilation environment, madvise() is declared
      // to take a caddr_t arg; casting it to void * results in an invalid
      // conversion error, so use char * instead.

    This allowed the compiler-rt build to finish and was tested successfully on
    i386-pc-solaris2.11 and x86_64-pc-linux-gnu.

    Differential Revision: (detail)
    by ro
  22. [yaml2obj/obj2yaml] - Make RawContentSection::Info Optional<>

    This allows to customize this field for "implicit" sections properly.

    Differential revision: (detail)
    by grimar
  23. [RISCV] Mark TLS as supported

    Inform Clang that TLS is implemented by LLVM for RISC-V

    Differential Revision: (detail)
    by lewis-revill
  24. [NFC][X86][MCA] Barcelona: add load/store/load-store-throughput tests (detail)
    by lebedevri
  25. [NFC][X86][MCA] BdVer2: add load-store-throughput test (detail)
    by lebedevri
  26. [X86] Add missing properties on llvm.x86.sse.{st,ld}mxcsr

    llvm.x86.sse.stmxcsr only writes to memory.
    llvm.x86.sse.ldmxcsr only reads from memory, and might generate an FPE.

    Reviewers: craig.topper, RKSimon

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by courbet
  27. [RISCV] Add lowering of global TLS addresses

    This patch adds lowering for global TLS addresses for the TLS models of
    InitialExec, GlobalDynamic, LocalExec and LocalDynamic.

    LocalExec support required using a 4-operand add instruction, which uses
    the fourth operand to express a relocation on the symbol. The necessary
    fixup is emitted when the instruction is emitted.

    Differential Revision: (detail)
    by lewis-revill

Started by timer (5 times)

This run spent:

  • 4 hr 6 min waiting;
  • 5 hr 9 min build duration;
  • 9 hr 16 min total from scheduled to completion.
Test Result (1 failure / -2)

Identified problems

Regression test failed

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

Ninja target failed

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

Compile Error

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