Started 29 days ago
Took 4 hr 11 min on green-dragon-02

Failed Build #14731 (Sep 19, 2019 2:23:30 PM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 372352
  • http://llvm.org/svn/llvm-project/cfe/trunk : 372353
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 372348
  • http://llvm.org/svn/llvm-project/zorg/trunk : 372342
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 372242
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 372317
Changes
  1. Revert "[CUDA][HIP] Fix typo in `BestViableFunction`"

    Broke the msan buildbots (see comments on rL372318 for more details).

    This reverts commit eb231d15825ac345b546f4c99372d1cac8f14f02. (detail)
    by hctim
  2. [ObjC][ARC] Skip debug instructions when computing the insert point of
    objc_release calls

    This fixes a bug where the presence of debug instructions would cause
    ARC optimizer to change the order of retain and release calls.

    rdar://problem/55319419 (detail)
    by ahatanak
  3. [AMDGPU] fixed underflow in getOccupancyWithNumVGPRs

    The function could return zero if an extreme number or
    registers were used. Minimal possible occupancy is 1.

    Differential Revision: https://reviews.llvm.org/D67771 (detail)
    by rampitec
  4. llvm-reduce: Follow-up to 372280, now with more-better msan fixing (detail)
    by dblaikie
  5. [lsan] Fix deadlock in dl_iterate_phdr.

    Summary:
    Do not grab the allocator lock before calling dl_iterate_phdr. This may
    cause a lock order inversion with (valid) user code that uses malloc
    inside a dl_iterate_phdr callback.

    Reviewers: vitalybuka, hctim

    Subscribers: jfb, #sanitizers, llvm-commits

    Tags: #sanitizers, #llvm

    Differential Revision: https://reviews.llvm.org/D67738 (detail)
    by eugenis
  6. Don't use invalidated iterators in FlattenCFGPass

    Summary:
    FlattenCFG may erase unnecessary blocks, which also invalidates iterators to those erased blocks.
    Before this patch, `iterativelyFlattenCFG` could try to increment a BB iterator after that BB has been removed and crash.

    This patch makes FlattenCFGPass use `WeakVH` to skip over erased blocks.

    Reviewers: dblaikie, tstellar, davide, sanjoy, asbirlea, grosser

    Reviewed By: asbirlea

    Subscribers: hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D67672 (detail)
    by kuhar
  7. [Analysis] Allow -scalar-evolution-max-iterations more than once

    At present, `-scalar-evolution-max-iterations` is a `cl::Optional`
    option, which means it demands to be passed exactly zero or one times.
    Our build system makes it pretty tricky to guarantee this. We often
    accidentally pass the flag more than once (but always with the same
    value) which results in an error, after which compilation fails:

    ```
    clang (LLVM option parsing): for the -scalar-evolution-max-iterations option: may only occur zero or one times!
    ```

    It seems reasonable to allow -scalar-evolution-max-iterations to be
    passed more than once. Quoting the [[ http://llvm.org/docs/CommandLine.html#controlling-the-number-of-occurrences-required-and-allowed | documentation ]]:

    > The cl::ZeroOrMore modifier ... indicates that your program will allow the option to be specified zero or more times.
    > ...
    > If an option is specified multiple times for an option of the cl::opt class, only the last value will be retained.

    Original patch by: Enrico Bern Hardy Tanuwidjaja <etanuwid@fb.com>

    Differential Revision: https://reviews.llvm.org/D67512 (detail)
    by smeenai
  8. [NFC][PowerPC] Fast-isel VSX support test

    We have fixed most of the VSX limitation in Fast-isel,
    so we can remove the -mattr=-vsx for most testcases now. (detail)
    by jsji
  9. gn build: Merge r372343 (detail)
    by gnsyncbot
  10. [SVFS] Vector Function ABI demangling.

    This patch implements the demangling functionality as described in the
    Vector Function ABI. This patch will be used to implement the
    SearchVectorFunctionSystem (SVFS) as described in the RFC:

    http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html

    A fuzzer is added to test the demangling utility.

    Patch by Sumedh Arani <sumedh.arani@arm.com>

    Differential revision: https://reviews.llvm.org/D66024 (detail)
    by fpetrogalli
  11. The LLD buildbot has some tests that are not reliable.
    Hopefully reducing the number of threads for the test will fix the issue.
    It seems that the quotes around the parameters means it tries to take everything as one argument. Bu using -j we can actually pass everything as one argument by attaching the j to the sv.

    Patch by Stefan Pintilie. (detail)
    by gkistanova
  12. [InstCombine] Simplify @llvm.usub.with.overflow+non-zero check (PR43251)

    Summary:
    This is again motivated by D67122 sanitizer check enhancement.
    That patch seemingly worsens `-fsanitize=pointer-overflow`
    overhead from 25% to 50%, which strongly implies missing folds.

    In this particular case, given
    ```
    char* test(char& base, unsigned long offset) {
      return &base - offset;
    }
    ```
    it will end up producing something like
    https://godbolt.org/z/luGEju
    which after optimizations reduces down to roughly
    ```
    declare void @use64(i64)
    define i1 @test(i8* dereferenceable(1) %base, i64 %offset) {
      %base_int = ptrtoint i8* %base to i64
      %adjusted = sub i64 %base_int, %offset
      call void @use64(i64 %adjusted)
      %not_null = icmp ne i64 %adjusted, 0
      %no_underflow = icmp ule i64 %adjusted, %base_int
      %no_underflow_and_not_null = and i1 %not_null, %no_underflow
      ret i1 %no_underflow_and_not_null
    }
    ```
    Without D67122 there was no `%not_null`,
    and in this particular case we can "get rid of it", by merging two checks:
    Here we are checking: `Base u>= Offset && (Base u- Offset) != 0`, but that is simply `Base u> Offset`

    Alive proofs:
    https://rise4fun.com/Alive/QOs

    The `@llvm.usub.with.overflow` pattern itself is not handled here
    because this is the main pattern, that we currently consider canonical.

    https://bugs.llvm.org/show_bug.cgi?id=43251

    Reviewers: spatel, nikic, xbolva00, majnemer

    Reviewed By: xbolva00, majnemer

    Subscribers: vsk, majnemer, xbolva00, hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D67356 (detail)
    by lebedevri

Started by timer (4 times)

This run spent:

  • 3 hr 12 min waiting;
  • 4 hr 11 min build duration;
  • 7 hr 24 min total from scheduled to completion.

Identified problems

Ninja target failed

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

Regression test failed

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

Missing test results

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