Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
815bf0f1 |
| 28-Aug-2024 |
Harini0924 <harinidonthula@gmail.com> |
Revert "[Clang] [Test] Use lit Syntax for Environment Variables in Clang subproject" (#106267)
Reverts llvm/llvm-project#102647
I am reverting this change because the `readfile` doesn't actually
Revert "[Clang] [Test] Use lit Syntax for Environment Variables in Clang subproject" (#106267)
Reverts llvm/llvm-project#102647
I am reverting this change because the `readfile` doesn't actually
perform any useful operation, and yet, for some reason, the test still
passed. This indicates that the modification was unnecessary and could
lead to confusion or unexpected behavior in the future.
show more ...
|
#
c975dc1d |
| 21-Aug-2024 |
Harini0924 <79345568+Harini0924@users.noreply.github.com> |
[clang] [test] Use lit Syntax for Environment Variables in Clang subproject (#102647)
This patch updates the clang tests by replacing shell command
substitutions with lit-compatible syntax for sett
[clang] [test] Use lit Syntax for Environment Variables in Clang subproject (#102647)
This patch updates the clang tests by replacing shell command
substitutions with lit-compatible syntax for setting and referencing
environment variables. Specifically, the use of shell-style variable
substitution (e.g., `DEFAULT_TRIPLE=`and `EXPECTED_RESOURCE_DIR=`) has
been replaced with `env` and `%{env}` to align with lit's internal shell
requirements. These changes ensure that environment variables are
properly set and accessed within the lit environment.
When using the lit internal shell with the command
`LIT_USE_INTERNAL_SHELL=1 ninja check-clang`, one common error
encountered is:
```
FAIL: Clang :: Driver/program-path-priority.c (19 of 20640)
******************** TEST 'Clang :: Driver/program-path-priority.c' FAILED ********************
Exit Code: 127
Command Output (stdout):
--
# RUN: at line 90
DEFAULT_TRIPLE=`/usr/local/google/home/harinidonthula/llvm-project/build/tools/clang/test/Driver/Output/program-path-priority.c.tmp/clang --version | grep "Target:" | cut -d ' ' -f2`
# executed command: 'DEFAULT_TRIPLE=`/usr/local/google/home/harinidonthula/llvm-project/build/tools/clang/test/Driver/Output/program-path-priority.c.tmp/clang' --version
# .---command stderr------------
# | 'DEFAULT_TRIPLE=`/usr/local/google/home/harinidonthula/llvm-project/build/tools/clang/test/Driver/Output/program-path-priority.c.tmp/clang': command not found
# `-----------------------------
# error: command failed with exit status: 127
```
To fix this issue, the patch replaces traditional shell substitutions
with lit's environment variable handling, ensuring compatibility with
the lit internal shell framework. This update applies to both the
handling of the `DEFAULT_TRIPLE` and `EXPECTED_RESOURCE_DIR` variables,
allowing the tests to pass when using the lit internal shell.
The patch also adds `env` to the `PWD` variable setting in the following
command to ensure the environment variable is correctly set within the
lit internal shell:
```
// RUN: %if system-linux %{ env PWD=/proc/self/cwd %clang -### -c --coverage %s -o foo/bar.o 2>&1 | FileCheck --check-prefix=PWD %s %}
```
fixes: #102395
[link to
RFC](https://discourse.llvm.org/t/rfc-enabling-the-lit-internal-shell-by-default/80179)
show more ...
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
ff07c9b7 |
| 28-Feb-2024 |
Fangrui Song <i@maskray.me> |
[Driver] Unify InstalledDir and Dir (#80527)
`Driver::ClangExecutable` is derived from:
* (-canonical-prefixes default): `realpath` on the executable path
* (-no-canonical-prefixes) argv[0] (con
[Driver] Unify InstalledDir and Dir (#80527)
`Driver::ClangExecutable` is derived from:
* (-canonical-prefixes default): `realpath` on the executable path
* (-no-canonical-prefixes) argv[0] (consult PATH if argv[0] is a word)
`Dir` and `ResourceDir` are derived from `ClangExecutable`. Both
variables are used to derive certain include and library paths.
`InstalledDir` is a related concept used to derive certain other paths.
`InstalledDir` is weird in the -canonical-prefixes mode: Clang
calls `make_absolute` but does not follow symlinks
(FIXME from 9ade6a9a747c49383ac747bd8ffaa6a0beaef71c).
This causes some search and library paths to be mix-and-matched.
The "Do a PATH lookup, if there are no directory components." logic
makes things worse.
`InstalledDir` is different when you invoke it via `PATH`:
```
% which clang
/usr/bin/clang
% clang -v |& grep InstalledDir
InstalledDir: /usr/bin
% /usr/lib/llvm-16/bin/clang -v |& grep InstalledDir
InstalledDir: /usr/lib/llvm-16/bin
```
I believe `InstalledDir` was a partial solution to
`-no-canonical-prefixes` and should be eventually removed.
This patch removes `SetInstallDir` and relies on Driver::Driver to set
`InstalledDir` to `Dir`. The behavior for regular file `clang` or
`-no-canonical-prefixes` is unchanged.
If a user creates a symlink to the regular file `clang` and uses the
default `-canonical-prefixes`, they now consistently get search and
library paths relative to the regular file `clang`, not mix-and-match
paths.
If a user creates a symlink to the regular file `clang` and replaces
some directorys from the actual installation, they should change the
symlink to a wrapper that calls the underlying clang with
`-no-canonical-prefixes`.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
8ac5e440 |
| 08-Apr-2021 |
Fangrui Song <i@maskray.me> |
[Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name
D13340 introduced this behavior which is not needed even for mips. This was raised on https://lists.llvm.org/pipermail/cfe-dev/2020-May
[Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name
D13340 introduced this behavior which is not needed even for mips. This was raised on https://lists.llvm.org/pipermail/cfe-dev/2020-May/065437.html but no action was taken.
This was raised again in https://lists.llvm.org/pipermail/cfe-dev/2021-April/067974.html "The LLVM host/target TRIPLE padding drama on Debian" as it caused confusion. This patch drops the behavior.
Differential Revision: https://reviews.llvm.org/D99996
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1 |
|
#
3452a0d8 |
| 19-Jul-2020 |
Fangrui Song <i@maskray.me> |
[Driver] -B: don't search for target triple prefixes
To match GCC (either crossing or not), which doesn't prepend target triple prefixes to `exec_prefixes`.
As an example, powerpc64le-linux-gnu-gcc
[Driver] -B: don't search for target triple prefixes
To match GCC (either crossing or not), which doesn't prepend target triple prefixes to `exec_prefixes`.
As an example, powerpc64le-linux-gnu-gcc does not search "powerpc64le-linux-gnu-${name}" in a -B path.
show more ...
|
Revision tags: llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3 |
|
#
fe591224 |
| 02-Jul-2020 |
David Spickett <david.spickett@linaro.org> |
[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
[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
show more ...
|
Revision tags: llvmorg-10.0.1-rc2 |
|
#
d6efc981 |
| 24-Jun-2020 |
David Spickett <david.spickett@linaro.org> |
Reland "[clang][Driver] Correct tool search path priority"
This reverts commit f570d5810485fa6fb2e1009f795a899d79bd429f.
The test was failing on MacOS if you set LLVM_DEFAULT_TARGET_TRIPLE. For exa
Reland "[clang][Driver] Correct tool search path priority"
This reverts commit f570d5810485fa6fb2e1009f795a899d79bd429f.
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.
show more ...
|
Revision tags: llvmorg-10.0.1-rc1 |
|
#
028571d6 |
| 11-May-2020 |
David Spickett <david.spickett@linaro.org> |
[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 ord
[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
show more ...
|