Started 5 mo 17 days ago
Took 40 min

Failed Build clang-r360004-t56189-b56189.tar.gz (May 5, 2019 7:39:17 PM)

Issues

Found 1 issues:
Error: <html>
+ . /Users/buildslave/jenkins/workspace/lnt-test-suite-x86_64-Os-flto/config/tasks/utils/lnt_submit.sh
++ echo '@@@ LNT Submit @@@'
@@@ LNT Submit @@@
++ '[' -n http://104.154.54.203/db_default/v4/nts/submitRun -a -n lnt-test-suite-x86_64-Os-flto ']'
+++ lnt submit http://104.154.54.203/db_default/v4/nts/submitRun /Users/buildslave/jenkins/workspace/lnt-test-suite-x86_64-Os-flto/lnt-sandbox/report.json
++ LNT_RESULT_URL='error: <html>

<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">

Build Log

Revision: 358206
Changes
  1. [libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not defining them

    When builing the hermetic static library, the compiler switch
    -fvisibility-global-new-delete-hidden is necessary to get the new and
    delete operator definitions made correctly. However, when those
    definitions are not included in the library, then this switch does harm.
    With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
    symbols makes it an error to leave them undefined or defined via dynamic
    linking that should generate PLTs for -shared linking (lld makes this a
    hard error even without -z defs). Though leaving the symbols undefined
    would usually work in practice if the linker were to allow it (and the
    user didn't pass -z defs), this actually indicates a real problem that
    could bite some target configurations more subtly at runtime. For
    example, x86-32 ELF -fpic code generation uses hidden visibility on
    declarations in the caller's scope as a signal that the call will never
    be resolved to a PLT entry and so doesn't have to meet the special ABI
    requirements for PLT calls (setting %ebx). Since these functions might
    actually be resolved to PLT entries at link time (we don't know what the
    user is linking in when the hermetic library doesn't provide all the
    symbols itself), it's not safe for the compiler to treat their
    declarations at call sites as having hidden visibility.

    Differential Revision: https://reviews.llvm.org/D61572 (detail)
    by phosek
  2. [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them

    When builing the hermetic static library, the compiler switch
    -fvisibility-global-new-delete-hidden is necessary to get the new and
    delete operator definitions made correctly. However, when those
    definitions are not included in the library, then this switch does harm.
    With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
    symbols makes it an error to leave them undefined or defined via dynamic
    linking that should generate PLTs for -shared linking (lld makes this a
    hard error even without -z defs). Though leaving the symbols undefined
    would usually work in practice if the linker were to allow it (and the
    user didn't pass -z defs), this actually indicates a real problem that
    could bite some target configurations more subtly at runtime. For
    example, x86-32 ELF -fpic code generation uses hidden visibility on
    declarations in the caller's scope as a signal that the call will never
    be resolved to a PLT entry and so doesn't have to meet the special ABI
    requirements for PLT calls (setting %ebx). Since these functions might
    actually be resolved to PLT entries at link time (we don't know what the
    user is linking in when the hermetic library doesn't provide all the
    symbols itself), it's not safe for the compiler to treat their
    declarations at call sites as having hidden visibility.

    Differential Revision: https://reviews.llvm.org/D61571 (detail)
    by phosek
Revision: 358206
Changes
  1. [clang-tidy] openmp-exception-escape check: point to the structured-block

    I'm not sure what i was thinking when i wrote it to point at the directive.
    It's at the very least confusing, and in the `for` is very misleading.

    We should point at the actual Stmt out of which the exception escapes,
    to highlight where it should be fixed e.g. via adding try-catch block.

    Yes, this breaks existing NOLINT, which is why this change needs to
    happen now, not any later. (detail)
    by lebedevri
Revision: 358206
Changes
  1. [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining them

    When builing the hermetic static library, the compiler switch
    -fvisibility-global-new-delete-hidden is necessary to get the new and
    delete operator definitions made correctly. However, when those
    definitions are not included in the library, then this switch does harm.
    With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
    symbols makes it an error to leave them undefined or defined via dynamic
    linking that should generate PLTs for -shared linking (lld makes this a
    hard error even without -z defs). Though leaving the symbols undefined
    would usually work in practice if the linker were to allow it (and the
    user didn't pass -z defs), this actually indicates a real problem that
    could bite some target configurations more subtly at runtime. For
    example, x86-32 ELF -fpic code generation uses hidden visibility on
    declarations in the caller's scope as a signal that the call will never
    be resolved to a PLT entry and so doesn't have to meet the special ABI
    requirements for PLT calls (setting %ebx). Since these functions might
    actually be resolved to PLT entries at link time (we don't know what the
    user is linking in when the hermetic library doesn't provide all the
    symbols itself), it's not safe for the compiler to treat their
    declarations at call sites as having hidden visibility.

    Differential Revision: https://reviews.llvm.org/D61571 (detail)
    by phosek

Started by upstream project relay-lnt-test-suite build number 7209
originally caused by:

This run spent:

  • 9.9 sec waiting;
  • 40 min build duration;
  • 40 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.