Started 15 days ago
Took 4 hr 57 min on green-dragon-02

Failed Build #14195 (Jun 9, 2019 6:55:46 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 362903
  • http://llvm.org/svn/llvm-project/cfe/trunk : 362887
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 362859
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 362745
  • http://llvm.org/svn/llvm-project/zorg/trunk : 362851
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 362866
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 362811
Changes
  1. [InstSimplify] enhance fcmp fold with never-nan operand

    This is another step towards correcting our usage of fast-math-flags when applied on an fcmp.
    In this case, we are checking for 'nnan' on the fcmp itself rather than the operand of
    the fcmp. But I'm leaving that clause in until we're more confident that we can stop
    relying on fcmp's FMF.

    By using the more general "isKnownNeverNaN()", we gain a simplification shown on the
    tests with 'uitofp' regardless of the FMF on the fcmp (uitofp never produces a NaN).
    On the tests with 'fabs', we are now relying on the FMF for the call fabs instruction
    in addition to the FMF on the fcmp.

    This is a continuation of D62979 / rL362879. (detail)
    by spatel
  2. [InstSimplify] add tests for fcmp with known-never-nan operands; NFC

    Opposite predicate for rL362742 / rL362879 / D62979 (detail)
    by spatel
  3. [MIR] Add simple PRE pass to MachineCSE

    This is the second part of the commit fixing PR38917 (hoisting
    partitially redundant machine instruction). Most of PRE (partitial
    redundancy elimination) and CSE work is done on LLVM IR, but some of
    redundancy arises during DAG legalization. Machine CSE is not enough
    to deal with it. This simple PRE implementation works a little bit
    intricately: it passes before CSE, looking for partitial redundancy
    and transforming it to fully redundancy, anticipating that the next
    CSE step will eliminate this created redundancy. If CSE doesn't
    eliminate this, than created instruction will remain dead and eliminated
    later by Remove Dead Machine Instructions pass.

    The third part of the commit is supposed to refactor MachineCSE,
    to make it more clear and to merge MachinePRE with MachineCSE,
    so one need no rely on further Remove Dead pass to clear instrs
    not eliminated by CSE.

    First step: https://reviews.llvm.org/D54839

    Fixes llvm.org/PR38917

    This is fixed recommit of r361356 after PowerPC64 multistage build failure. (detail)
    by anton-afanasyev
  4. [CaptureTracking] Don't let comparisons against null escape inbounds pointers

    Pointers that are in-bounds (either through dereferenceable_or_null or
    thorough a getelementptr inbounds) cannot be captured with a comparison
    against null. There is no way to construct a pointer that is still in
    bounds but also NULL.

    This helps safe languages that insert null checks before load/store
    instructions. Without this patch, almost all pointers would be
    considered captured even for simple loads. With this patch, an icmp with
    null will not be seen as escaping as long as certain conditions are met.

    There was a lot of discussion about this patch. See the Phabricator
    thread for detals.

    Differential Revision: https://reviews.llvm.org/D60047 (detail)
    by aykevl
  5. [bindings/go] Add wrappers for atomic operations.

    This patch adds Go bindings for atomic operations in LLVM.

    Differential Revision: https://reviews.llvm.org/D61034 (detail)
    by aykevl
  6. [X86] NFCI : Comment updation for EVEX to VEX translation.

    Reviewers: llvm-commits, jbhateja

    Reviewed By: jbhateja

    Subscribers: llvm-commits

    Tags: #llvm

    Differential Revision: https://reviews.llvm.org/D63055 (detail)
    by Jatin Bhateja
  7. Use for-range loop. NFCI. (detail)
    by rksimon

Started by timer (5 times)

This run spent:

  • 4 hr 45 min waiting;
  • 4 hr 57 min build duration;
  • 9 hr 42 min total from scheduled to completion.
Test Result (1 failure / -1)

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