search for: bugpoint_topts

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

...ch longer, >> though. :( > > I updated the bug explaining what I'm seeing. I think the correct fix > is to use absolute paths to tools being tested rather than relying on > PATH. So I tried adding this to llvm.exp::substitute: [...] global llvmdsymutil valgrind grep gas bugpoint_topts llvmtoolsdir [...] # Replace references to llvm tools to tools in OBJDIR. regsub -all {bugpoint } $new_line "$llvmtoolsdir/bugpoint " new_line regsub -all {llc } $new_line "$llvmtoolsdir/llc " new_line regsub -all {lli } $new_line "$llvmtoolsdir/lli " new_line...

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