Started 1 yr 0 mo ago
Took 56 min

Failed Build clang-r359537-t56005-b56005.tar.gz (Apr 30, 2019 3:02:10 AM)


Found 1 issues:
Error: <html>
+ . /Users/buildslave/jenkins/workspace/lnt-test-suite-x86_64-O3-flto/config/tasks/utils/
++ echo '@@@ LNT Submit @@@'
@@@ LNT Submit @@@
++ '[' -n -a -n lnt-test-suite-x86_64-O3-flto ']'
+++ lnt submit /Users/buildslave/jenkins/workspace/lnt-test-suite-x86_64-O3-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
  1. [TargetLowering] Change getOptimalMemOpType to take a function attribute list

    The MachineFunction wasn't used in getOptimalMemOpType, but more importantly,
    this allows reuse of findOptimalMemOpLowering that is calling getOptimalMemOpType.

    This is the groundwork for the changes in D59766 and D59787, that allows
    implementation of TTI::getMemcpyCost.

    Differential Revision: (detail)
    by sjoerdmeijer
  2. MSan: handle llvm.lifetime.start intrinsic

    When a variable goes into scope several times within a single function
    or when two variables from different scopes share a stack slot it may
    be incorrect to poison such scoped locals at the beginning of the
    In the former case it may lead to false negatives (see, in the latter - to
    incorrect reports (because only one origin remains on the stack).

    If Clang emits lifetime intrinsics for such scoped variables we insert
    code poisoning them after each call to llvm.lifetime.start().
    If for a certain intrinsic we fail to find a corresponding alloca, we
    fall back to poisoning allocas for the whole function, as it's now
    impossible to tell which alloca was missed.

    The new instrumentation may slow down hot loops containing local
    variables with lifetime intrinsics, so we allow disabling it with
    -mllvm -msan-handle-lifetime-intrinsics=false.

    Reviewers: eugenis, pcc

    Subscribers: hiraditya, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by glider
  3. [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.

    The PrologEpilogInserter need to insert a DW_OP_deref_size before
    prepending a memory location expression to an already implicit
    expression to avoid having the existing expression act on the memory
    address instead of the value behind it.

    The reason for using DW_OP_deref_size and not plain DW_OP_deref is that
    big-endian targets need to read the right size as simply truncating a
    larger read would yield the wrong result (LSB bytes are not at the lower

    This re-commit fixes issues reported in the first one. Namely deref was
    inserted under wrong conditions and additionally the deref_size argument
    was incorrectly encoded.

    Differential Revision: (detail)
    by markus

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

This run spent:

  • 13 min waiting;
  • 56 min build duration;
  • 56 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.