Summary:
When bugpoint attempts to find the other executables it needs to run,
such as `opt` or `clang`, it tries searching the user's PATH. However,
in many cases, the 'bugpoint' executable is part of an LLVM build, and
the 'opt' executable it's looking for is in that same directory.
Many LLVM tools handle this case by using the `Paths` parameter of
`llvm::sys::findProgramByName`, passing the parent path of the currently
running executable. Do this same thing for bugpoint. However, to
preserve the current behavior exactly, first search the user's PATH,
and then search for 'opt' in the directory containing 'bugpoint'.
Test Plan:
`check-llvm`. Many of the existing bugpoint tests no longer need to use the
`--opt-command` option as a result of these changes.
Reviewers: MatzeB, silvas, davide
Reviewed By: MatzeB, davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D54884
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@348734 91177308-0d34-0410-b5e6-96231b3b80d8
If the tests don't use the in-tree opt, we're liable to see some silly
error messages due to the version mismatch (missing flags, etc).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324703 91177308-0d34-0410-b5e6-96231b3b80d8
debugger.
When bugpoint hacks at a testcase it may at one point create illegal
debug info metadata that won't even pass the Verifier. A bugpoint
*driver* built with assertions should not assert on it, but reject the
malformed intermediate step and continue to do its job.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284490 91177308-0d34-0410-b5e6-96231b3b80d8
Petr Hosek