Commit Graph

4 Commits

Author SHA1 Message Date
David Spickett fe5912249e [clang][Driver] Fix tool path priority test failures
Summary:
Failure type 1:
This test can fail when the path of the build includes the strings
we're checking for. E.g "/gcc" is found in ".../gcc_7.3.0/..."

To correct this look for '"' on the end of all matches. So that we
only match the end of paths printed by clang -###.
(which would be ".../gcc_7.3.0/.../gcc" for the example)

Also look for other gcc names like gcc-x.y.z in the first check.
This confirms that the copy of clang we made is isolated as expected.

Failure type 2:
If you use a triple like "powerpc64le-linux-gnu" clang actually reports
"powerpc64le-unknown-linux-gnu". Then it searches for the
former.

That combined with Mac OS adding a version number to cmake's triple
means we can't trust cmake or clang to give us the one default triple.
To fix the test, write to both names. As they don't overlap with our
fake triple, we're still showing that the lookup works.

Reviewers: MaskRay, stevewan

Reviewed By: stevewan

Subscribers: miyuki, JDevlieghere, steven.zhang, stevewan, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D83055
2020-07-15 09:37:09 +01:00
David Spickett d6efc98116 Reland "[clang][Driver] Correct tool search path priority"
This reverts commit f570d58104.

The test was failing on MacOS if you set
LLVM_DEFAULT_TARGET_TRIPLE. For example if you set it to
"x86_64-apple-darwin" clang actually uses
"x86_64-apple-darwin<version>".

To fix this get default triple from clang itself during the
test instead of substituting it in via lit.
2020-06-25 09:33:43 +01:00
David Spickett f570d58104 Revert "[clang][Driver] Correct tool search path priority"
Revert 028571d608 to investigate
MacOS failure.
(also the review link was incorrect, should be
https://reviews.llvm.org/D79842)
2020-06-22 14:18:54 +01:00
David Spickett 028571d608 [clang][Driver] Correct tool search path priority
Summary:
As seen in:
https://bugs.llvm.org/show_bug.cgi?id=45693

When clang looks for a tool it has a set of
possible names for it, in priority order.
Previously it would look for these names in
the program path. Then look for all the names
in the PATH.

This means that aarch64-none-elf-gcc on the PATH
would lose to gcc in the program path.
(which was /usr/bin in the bug's case)

This changes that logic to search each name in both
possible locations, then move to the next name.
Which is more what you would expect to happen when
using a non default triple.

(-B prefixes maybe should follow this logic too,
but are not changed in this patch)

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D79988
2020-06-22 09:41:13 +01:00