Started 11 days ago
Took 5 hr 55 min on green-dragon-21

Failed Build #18201 (Jun 12, 2019 9:55:01 PM)

  • : 363224
  • : 363220
  • : 363167
  • : 362745
  • : 363219
  • : 363150
  1. [X86] Add tests for some the special cases in EVEX to VEX to the evex-to-vex-compress.mir test. (detail/ViewSVN)
    by ctopper
  2. [SimplifyCFG] revert the last commit.

    I ran ALL the test suite locally, so I will look into this... (detail/ViewSVN)
    by shawnl
  3. [SimplifyCFG] NFC, update Switch tests to HEAD so I can

    see if my changes change anything

    Also add baseline tests to show effect of later patches.

    Differential Revision: (detail/ViewSVN)
    by shawnl
  4. X86: Clean up pass initialization

    - Remove redundant initializations from pass constructors that were
      already being initialized by LLVMInitializeX86Target().

    - Add initialization function for the FPS pass.

    Reviewers: craig.topper

    Reviewed By: craig.topper

    Subscribers: hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: (detail/ViewSVN)
    by tstellar
  5. Revert r361811: 'Re-commit r357452 (take 2): "SimplifyCFG SinkCommonCodeFromPredecessors ...'

    We have observed some failures with internal builds with this revision.

    - Performance regressions:
      - llvm's SingleSource/Misc evalloop shows performance regressions (although these may be red herrings).
      - Benchmarks for Abseil's SwissTable.
    - Correctness:
      - Failures for particular libicu tests when building the Google AppEngine SDK (for PHP).

    hwennborg has already been notified, and is aware of reproducer failures. (detail/ViewSVN)
    by dlj
  6. Make GCC in C++03 Unsupported

    This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists.

    Below is the rational for this decision.

    libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.

    Our C++03 users are all using Clang. They must be.  Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.

    Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::

    * Improve Correctness:

    Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.

    * Achieve ABI stability between C++03 and C++11

    Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.

    * Decrease Compile Times and Memory Usage:

    Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.

    * Decrease Binary Size

    Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.

    Reviewers: ldionne, mclow.lists, EricWF

    Reviewed By: ldionne, EricWF

    Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc

    Differential Revision: (detail/ViewSVN)
    by ericwf
  7. [SLP] Update propagate_ir_flags.ll test to check that we do retain the common subset, NFC. (detail/ViewSVN)
    by dinar

Started by upstream project clang-stage2-Rthinlto_relay build number 1607
originally caused by:

This run spent:

  • 2 ms waiting;
  • 5 hr 55 min build duration;
  • 5 hr 55 min total from scheduled to completion.

Identified problems

No identified problem

No problems were identified. If you know why this problem occurred, please add a suitable Cause for it.