Started 10 days ago
Took 9 hr 38 min on green-dragon-13

Failed Build #6420 (Jun 8, 2019 9:48:15 AM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 362879
  • http://llvm.org/svn/llvm-project/cfe/trunk : 362877
  • 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/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 1 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.

    I'll update the 'ult' case below here as a follow-up assuming no problems here.

    Differential Revision: https://reviews.llvm.org/D62979 (detail/ViewSVN)
    by spatel
  2. fix a typo unavaliable=>unavailable (detail/ViewSVN)
    by sylvestre
  3. [analyzer][NFC][tests] Pre-normalize expected-plists

    As suggested in the review for D62949, this patch pre-normalizes the
    reference expected output plist files by removing lines containing
    fields for which we expect differences that should be ignored. (detail/ViewSVN)
    by hubert.reinterpretcast
  4. [analyzer][NFC][tests] Remove unused expected-plist files (detail/ViewSVN)
    by hubert.reinterpretcast
  5. [NFC] Added tests for D63038 (detail/ViewSVN)
    by xbolva00
  6. [ARM] Adjust isLegalT1AddressImmediate for non-legal types

    Types such as float and i64's do not have legal loads in Thumb1, but will still
    be loaded with a LDR (or potentially multiple LDR's). As such we can treat the
    cost of addressing mode calculations the same as an i32 and get some optimisation
    benefits.

    Differential Revision: https://reviews.llvm.org/D62968 (detail/ViewSVN)
    by dmgreen
  7. [ARM] Add MVE addressing to isLegalT2AddressImmediate

    Now with MVE being added, we can add the vector addressing mode costs for it.
    These are generally imm7 multiplied by the size of the type being loaded /
    stored.

    Differential Revision: https://reviews.llvm.org/D62967 (detail/ViewSVN)
    by dmgreen
  8. [ARM] Add fp16 addressing to isLegalT2AddressImmediate

    The fp16 version of VLDR takes a imm8 multiplied by 2. This updates the costs
    to account for those, and adds extra testing. It is dependant upon hasFPRegs16
    as this is what the load/store instructions require.

    Differential Revision: https://reviews.llvm.org/D62966 (detail/ViewSVN)
    by dmgreen
  9. [ARM] Add extra gep costmodel tests for MVE and half float. NFC (detail/ViewSVN)
    by dmgreen
  10. [ARM] Add HasNEON for all Neon patterns in ARMInstrNEON.td. NFCI

    We are starting to add an entirely separate vector architecture to the ARM
    backend. To do that we need at least some separation between the existing NEON
    and the new MVE code. This patch just goes through the Neon patterns and
    ensures that they are predicated on HasNEON, giving MVE a stable place to start
    from.

    No tests yet as this is largely an NFC, and we don't have the other target that
    will treat any of these intructions as legal.

    Differential Revision: https://reviews.llvm.org/D62945 (detail/ViewSVN)
    by dmgreen
  11. [SystemZ]  Fix CMakeLists.txt for alphabetical order (NFC). (detail/ViewSVN)
    by jonpa

Started by upstream project clang-stage2-cmake-RgSan_relay build number 1135
originally caused by:

This run spent:

  • 2 ms waiting;
  • 9 hr 38 min build duration;
  • 9 hr 38 min total from scheduled to completion.
Test Result (no failures)

    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