Started 2 yr 5 mo ago
Took 1 hr 28 min on green-dragon-13

Success Build r302606 (#5811) (May 9, 2017 6:09:53 PM)

Subproject Builds

Revision: 302606
Changes
  1. [WebAssembly] Fix build error in wasm YAML code

    This warning didn't show up on my local build
    but is causing the bots to fail.  Seems like a
    bad idea to have types and variables with the
    same name anyhow.

    Differential Revision: https://reviews.llvm.org/D33022 (detail/ViewSVN)
    by sbc
  2. [InstCombine] add helper function for add X, C folds; NFCI (detail/ViewSVN)
    by spatel
  3. Attempt to unbreak Libc++ test configuration (detail/ViewSVN)
    by ericwf
  4. When instantiating a friend function template, don't forget to inherit default template arguments from other declarations. (detail/ViewSVN)
    by rsmith
  5. Fix test runtime environment on Windows (detail/ViewSVN)
    by ericwf
  6. [WebAssembly] Improve libObject support for wasm imports and exports

    Previously we had only supported the importing and
    exporting of functions and globals.

    Also, add usefull overload of getWasmSymbol() and
    getNumberOfSymbols() in support of lld port.

    Differential Revision: https://reviews.llvm.org/D33011 (detail/ViewSVN)
    by sbc
  7. Fix misspelling of environment throughout libc++ (detail/ViewSVN)
    by ericwf
  8. [InstCombine] add tests for andn; NFC (detail/ViewSVN)
    by spatel
  9. [ubsan] Mark overflow checks with !nosanitize

    Sanitizer instrumentation generally needs to be marked with !nosanitize,
    but we're not doing this properly for ubsan's overflow checks.

    r213291 has more information about why this is needed. (detail/ViewSVN)
    by Vedant Kumar
  10. [ProfileSummary] Make getProfileCount a non-static member function.

    This change is required because the notion of count is different for
    sample profiling and getProfileCount will need to determine the
    underlying profile type.

    Differential revision: https://reviews.llvm.org/D33012 (detail/ViewSVN)
    by eraman
  11. Don't mark a member as a member specialization until we know we're keeping the specialization.

    This improves our behavior in a few ways:

    * We now guarantee that if a member is marked as being a member
       specialization, there will actually be a member specialization declaration
       somewhere on its redeclaration chain. This fixes a crash in modules builds
       where we would try to check that there was a visible declaration of the
       member specialization and be surprised to not find any declaration of it at
       all.

    * We don't set the source location of the in-class declaration of the member
       specialization to the out-of-line declaration's location until we have
       actually finished merging them. This fixes some very silly looking
       diagnostics, where we'd point a "previous declaration is here" note at the
       same declaration we're complaining about. Ideally we wouldn't mess with the
       prior declaration's location at all, but too much code assumes that the
       first declaration of an entity is a reasonable thing to use as an indication
       of where it was declared, and that's not really true for a member
       specialization unless we fake it like this. (detail/ViewSVN)
    by rsmith
  12. FunctionImport: Simplify function llvm::thinLTOInternalizeModule. NFCI. (detail/ViewSVN)
    by pcc

Started by upstream project phase2_modules_relay build number 3980
originally caused by:

This run spent:

  • 11 ms waiting;
  • 1 hr 28 min build duration;
  • 1 hr 28 min total from scheduled to completion.