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

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 4 16:52:03 PDT 2016


I think this test needs to create a temporary directory and cd into it:

llvm-nm a.out | FileCheck %s

this could be using a a.out from some other test if the scheduling is
just right.

Thanks!

Cheers,
Rafael


On 4 June 2016 at 16:30, Sean Silva via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
>
>
> 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. =/
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>


More information about the llvm-commits mailing list