[lld] r263070 - [lto] Add saving the LTO .o file to -save-temps.

Sat Jun 4 16:30:25 PDT 2016

On Sat, Jun 4, 2016 at 1:43 PM, Chandler Carruth <chandlerc at google.com>
wrote:

> Sorry to dredge up an old commit, but I just saw this test spuriously fail:
>
>
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/14073
>
> My commit seems unlikely to have triggered this, and the next build
> "fixed" the test. I'm worried there is something non-deterministic going on
> here.
>

Thanks for bringing attention to this. This is actually somewhat more
troubling.

This test case links together save-temps.ll (containing just the function
`foo`) with Inputs/save-temps.ll (containing just the function `bar`). Yet
the error message below shows a reference to a function `f`. I'm baffled
about how a function `f` could end up in the nm output here.

Maybe `f` is the string `foo` being cut off, but that doesn't make sense
since FileCheck's output indicates that it was `bar` that wasn't seen, and
`bar` would have come first (unless this is a coincidence of the cut off
with an ordering nondeterminism).

Expanding the possibilities to "the bot may be unreliable / cosmic ray"
territory, this could be that Inputs/linkonce.ll or another file containing
a function `f` is somehow getting used instead of Inputs/save-temps.ll
(which, assuming LLD is deterministic, makes sense since `bar` is missing
and `f` was found in its place).

FAIL: lld :: ELF/lto/save-temps.ll (26092 of 27438)
******************** TEST 'lld :: ELF/lto/save-temps.ll' FAILED
********************
Script:
--
rm -f a.out a.out.lto.bc a.out.lto.o
llvm-as /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
-o /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp.o
llvm-as /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/Inputs/save-temps.ll
-o /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp2.o
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/ld.lld
-shared -m elf_x86_64
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp.o
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp2.o
-save-temps
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/llvm-nm
a.out | /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/llvm-nm
a.out.lto.bc | /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/llvm-nm
a.out.lto.o | /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
llvm-dis a.out.lto.bc
--
Exit Code: 1

Command Output (stderr):
--
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll:18:10:
error: expected string not found in input
; CHECK: T bar
         ^
<stdin>:1:1: note: scanning from here
0000000000002000 d _DYNAMIC
^
<stdin>:2:18: note: possible intended match here
0000000000001000 T f
                 ^

--

********************

> When reading this patch I noticed one thing below:
>
> On Wed, Mar 9, 2016 at 2:34 PM Sean Silva via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>>
>> ==============================================================================
>> --- lld/trunk/test/ELF/lto/save-temps.ll (original)
>> +++ lld/trunk/test/ELF/lto/save-temps.ll Wed Mar  9 16:30:05 2016
>> @@ -1,10 +1,11 @@
>>  ; REQUIRES: x86
>> -; RUN: rm -f %t.so %t.so.lto.bc
>> +; RUN: rm -f %t.so %t.so.lto.bc %t.so.lto.o
>>  ; RUN: llvm-as %s -o %t.o
>>  ; RUN: llvm-as %p/Inputs/save-temps.ll -o %t2.o
>>  ; RUN: ld.lld -shared -m elf_x86_64 %t.o %t2.o -o %t.so -save-temps
>>  ; RUN: llvm-nm %t.so | FileCheck %s
>>  ; RUN: llvm-nm %t.so.lto.bc | FileCheck %s
>> +; RUN: llvm-nm %t.so.lto.o | FileCheck %s
>>
>>  target triple = "x86_64-unknown-linux-gnu"
>>  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
>> @@ -13,5 +14,5 @@ define void @foo() {
>>    ret void
>>  }
>>
>> -; CHECK-DAG: T bar
>> -; CHECK-DAG: T foo
>> +; CHECK: T bar
>> +; CHECK: T foo
>>
>
> This change seems odd and unrelated to me.
>
> If the CHECK-DAG was required, that shows some lack of deterministic
> output here. This change seems unlikely to have fixed any such
> non-determinism.
>

The CHECK-DAG was because the intent of the test actually doesn't imply an
order. For example, down the road, LTO is likely to do function layout and
so these may end up in a different order, and IMO the test shouldn't be
fragile.  Rui objected because it "doesn't currently" matter, and I
assented.

-- Sean Silva

>
> Sadly, this seems unlikely to explain the spurious failure I just saw. =/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160604/7d568fa5/attachment.html>