The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb10461d114783a1548201928549ace09755: add -nogpulib to some AMDGPU tests
* 9155e517e6e1cda474d0d0fa82f71696c325bc10: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5bbcca1364c2d4ae06127011eaba6389: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f0d1da8d8e421f4a628d7ec64d6e365: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
* ab68df505e5bb8808ee44f53044b50ca7575098e: add -resource-dir= and -fvisibility=hidden
to some -fsanitize=cfi tests
* d5ca1602f64114f612ad5630f04e4aa90591c78d: --rtlib=platform without --unwindlib= may fail if CLANG_DEFAULT_UNWINDLIB=unwindlib
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb10461d114783a1548201928549ace09755: add -nogpulib to some AMDGPU tests
* 9155e517e6e1cda474d0d0fa82f71696c325bc10: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5bbcca1364c2d4ae06127011eaba6389: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f0d1da8d8e421f4a628d7ec64d6e365: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
This reverts commit e39bf32b3bc2f0cc21d783ba789bd82553493875.
Some tests have different behaviors depent on whether certain directories/files are present on the host.
An incomplete list from https://lab.llvm.org/buildbot/#/builders/109/builds/70149
csky-toolchain.c
riscv*-toolchain.c
fuchsia.*
hip-*
ohos.c
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
Summary:
This added a check for no unknown argument warnings. This apparently
occurs in the Windows toolchain as it cannot find a toolchain. This
patch fixes it by just ignoring this warning.
The offloading toolchain makes heavy use of options beginning with
`--o`. This is problematic when combined with the joined `-o` flag. In
the following situation, the user will not get the expected output and
will not notice as the expected output will still be written.
```
clang++ -x cuda foo.cu -offload-arch=sm_80 -o foo
```
This patch introduces a warning that checks for joined `-o` arguments
that would also be a valid driver argument if an additional `-` were
added. I believe this situation is uncommon enough to warrant a warning,
and can be trivially fixed by the end user by using the more common
separate form instead.
Reviewed By: tra, MaskRay
Differential Revision: https://reviews.llvm.org/D135389
This patch adds an additional check for if an options passed to the
Clang driver could've been intended for the clang compiler. This is
primarily done for the times when a user attempts to pass an option like
`-ast-dump` to the driver instead.
Reviewed By: MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D134550
When nonexistent linker inputs are passed to the driver, the linker
now errors out, instead of the compiler. If the linker does not run,
clang now emits a "warning: linker input unused" instead of an error
for nonexistent files.
The motivation for this change is that I noticed that
`clang-cl /winsysroot sysroot main.cc ole32.lib` emitted a
"ole32.lib not found" error, even though the linker finds it just fine when
I run `clang-cl /winsysroot sysroot main.cc /link ole32.lib`.
The same problem occurs if running `clang-cl main.cc ole32.lib` in a
non-MSVC shell.
The problem is that DiagnoseInputExistence() only looked for libs in %LIB%,
but MSVCToolChain uses much more involved techniques.
For this particular problem, we could make DiagnoseInputExistence() ask
the toolchain to see if it can find a .lib file, but in general the
driver can't know what the linker will do to find files, so it shouldn't
try. For example, if we implement PR24616, lld-link will look in the
registry to determine a good default for %LIB% if it isn't set.
This is less or a problem for the gcc driver, since .a paths there are
either passed via -l flags (which honor -L), or via a qualified path
(that doesn't honor -L) -- but for example ld.lld's --chroot flag
can also trigger this problem. Without this patch,
`clang -fuse-ld=lld -Wl,--chroot,some/dir /file.o` will complain that
`/file.o` doesn't exist, even though
`clang -fuse-ld=lld -Wl,--chroot,some/dir -Wl,/file.o` succeeds just fine.
This implements rnk's suggestion on the old bug PR27234.
Differential Revision: https://reviews.llvm.org/D109624
With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process.
This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus.
It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process.
Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means.
This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process.
At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before.
Differential Revision: https://reviews.llvm.org/D69825
OptTable treats arguments starting with / that aren't a known option
as filenames. This means lld-link's and clang-cl's typo correction for
unknown flags didn't do spell checking for misspelled options that start
with /.
I first tried changing OptTable, but that got pretty messy, see PR41787
comments 2 and 3.
Instead, let lld-link's and clang's (including clang-cl's) "file not
found" diagnostic check if a non-existent file looks like it could be a
mis-spelled option, and if so add a "did you mean" suggestion to the
"file not found" diagnostic.
While here, make formatting of a few diagnostics a bit more
self-consistent.
Fixes PR41787.
Differential Revision: https://reviews.llvm.org/D62276
llvm-svn: 361518
Summary:
https://reviews.llvm.org/D46776 added better support for prefixes for the
"did you mean ...?" command line option suggestions. One of the tests was
checking against the `-debug-info-macro` option, which was failing on the
PS4 build bot. Tests would succeed against the `--help` and `--version`
options.
From https://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain.pdf, it
looks like the PS4 SDK forces optimizations and *could be* disabling the
`-debug-info-macro` altogether.
This diff removes `-debug-info-macro` altogether.
Patch by Arnaud Coomans!
Test Plan: untested since we do not have access to a PS4 with the SDK.
Reviewers: cfe-commits, modocache
Reviewed By: modocache
Differential Revision: https://reviews.llvm.org/D50410
llvm-svn: 341327
Summary:
When https://reviews.llvm.org/D46776 landed to improve the behavior of
`llvm::OptTable::findNearest`, a PS4 buildbot began failing due to an
assertion that a suggestion "-debug-info-macro" should be provided for
the unrecognized option `clang -cc1as -debug-info-macros`. All other
buildbots succeeded in this check, and the PS4 buildbot succeeded in the
other `findNearest` tests.
Temporarily loosen this check in order to reland the `findNearest`
change.
Test Plan: check-clang
llvm-svn: 332804
I discovered that '-i' is a command line option for the driver,
however it actually does not do anything and is not supported by any
other compiler. In fact, it is completely undocumented for Clang.
I found a couple of instances of people confusing it with one of
the variety of other command line options that control the driver.
Because of this, we should delete this option so that it is clear
that it isn't valid.
HOWEVER, I found that GCC DOES support -imultilib, which the -i
was hiding our lack of support for. We currently only use imultilib
for the purpose of forwarding to gfortran (in a specific test written
by chandlerc for this purpose).
imultilib is a rarely used (if ever?) feature that I could find no
references to on the internet, and in fact, my company's massive test
suite has zero references to it ever being used.
SO, this patch removes the -i option so that we will now give an error
on its usage (so that it won't be confused with -I), and replaces it with
-imultilib, which is now specified as a gfortran_group option.
Differential Revision: https://reviews.llvm.org/D44032
llvm-svn: 326623
Summary:
There are only two valid integrated Clang driver tools: `-cc1` and
`-cc1as`. If a user asks for an unknown tool, such as `-cc1asphalt`,
an error message is displayed to indicate that there is no such tool,
but the message doesn't indicate what the valid options are.
Include the valid options in the error message.
Test Plan: `check-clang`
Reviewers: sepavloff, bkramer, phosek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42004
llvm-svn: 322517
Summary:
In https://reviews.llvm.org/D41733, the driver was modified such that,
when a user provided a mispelled option such as `-hel`, it would
suggest a valid option with a nearby edit distance: "did you mean
'-help'?".
Add these suggestions to invocations of `clang -cc1as` as well.
Test Plan: `check-clang`
Reviewers: v.g.vassilev, bruno
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42001
llvm-svn: 322445
Summary:
The `llvm::OptTable::findNearest` bug fixed in
https://reviews.llvm.org/D41873 manifested itself as the following
erroneous message when invoking Clang:
```
clang -version
clang-6.0: error: unknown argument '-version', did you mean 'version'?
```
Add a test to catch any future regressions to the now correct behavior,
which asks "did you mean '--version'?".
Test Plan: `check-clang`
Reviewers: v.g.vassilev, teemperor, ruiu, jroelofs, yamaguchi
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41912
llvm-svn: 322220
Summary:
Depends on https://reviews.llvm.org/D41732.
Utilities such as `opt`, when invoked with arguments that are very
nearly spelled correctly, suggest the correctly spelled options:
```
bin/opt -hel
opt: Unknown command line argument '-hel'. Try: 'bin/opt -help'
opt: Did you mean '-help'?
```
Clang, on the other hand, prior to this commit, does not:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel'
```
This commit makes use of the new libLLVMOption API from
https://reviews.llvm.org/D41732 in order to provide correct suggestions:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel', did you mean '-help'?
```
Test Plan: `check-clang`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, bruno
Reviewed By: bruno
Subscribers: bruno, jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D41733
llvm-svn: 321917
This is recommit of r302775, reverted in r302777 due to a fail in
clang-tidy. Original mesage is below.
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 303756
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 302775
Summary:
MSVC's driver accepts all unknown arguments but warns about them. clang
by default rejects all unknown arguments. This causes issues
specifically with build systems such as autoconf which liberally pass
things such as $LDFLAGS to the compiler and expect everything to work.
This patch teaches clang-cl to ignore unknown driver arguments.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16511
llvm-svn: 258720
This doesn't change a lot since clang still thinks it knows all of the
-f*, -m* and -W* options for example.
Other than the options clang explicitly claims to know, this fixes pr9701.
llvm-svn: 191249
