Displaying 3 results from an estimated 3 matches for "1opt".
Did you mean:
10pt
2010 Dec 09
0
[LLVMdev] Parallel testsuite run breaks
greened at obbligato.org (David A. Greene) writes:
> For now, I think if I tweak the way I do the build to always build
> without pointing to llvm-gcc first, build and test LLVM then build
> llvm-gcc and re-build LLVM, it should work. It will take much longer,
> though. :(
I updated the bug explaining what I'm seeing. I think the correct fix
is to use absolute paths to tools
2010 Dec 10
2
[LLVMdev] Parallel testsuite run breaks
...llvm-nm } $new_line "$llvmtoolsdir/llvm-nm " new_line
regsub -all {llvm-prof } $new_line "$llvmtoolsdir/llvm-prof " new_line
regsub -all {llvm-ranlib } $new_line "$llvmtoolsdir/llvm-ranlib " new_line
regsub -all {([^a-zA-Z_-])opt } $new_line "$llvmtoolsdir/\\1opt " new_line
regsub -all {opt } $new_line "$llvmtoolsdir/opt " new_line
regsub -all {tblgen } $new_line "$llvmtoolsdir/tblgen " new_line
It appears to work for clang tests:
[x86_64-off-opt]: FAIL: Clang :: CodeCompletion/ordinary-name.c (432 of 8411)
[x86_64-off-opt]: *...
2010 Dec 09
2
[LLVMdev] Parallel testsuite run breaks
Jason Kim <jasonwkim at google.com> writes:
>>> There is definitely something to this. If I take a random failing
>>> testcase and run the test in isolation in the shell, it works. So
>>> what, if anything, does lit/FileCheck/etc. do that might run
>>> interference if there is another copy of lit/FileCheck/etc. running
>>> at the same time? I