These two tests copy the clang binary into the test tree and assume it
will run from a new location. This is incompatible with relative rpath
values, which is what you typically get in a dylib developer build.
Disable these tests if shared libraries are involved. Another way to
make these tests work would be to update the loader search path
environment variables, but it is difficult to do that portably.
This introduces options `-floop-interchange` and `-fno-loop-interchange`
to enable/disable the loop-interchange pass. This is part of the work
that tries to get that pass enabled by default (#124911), where it was
remarked that a user facing option to control this would be convenient
to have. The option name is the same as GCC's.
The Flag form options are accepted and silently ignored, which can be
surprising. The Eq form is supposed to be used instead, e.g.
-fprofile-sample-use=a.afdo.
Since we does not intend to support GCC's "fbaata.afdo" filename, just
remove the two options. While here, clean up code as -fauto-profile= is
an alias.
Pull Request: https://github.com/llvm/llvm-project/pull/113528
Follow-up on https://github.com/llvm/llvm-project/pull/109607, we have a
use case on Windows-on-ARM64 where `cmake -G "Unix Makefiles"` generates
`-fuse-ld=lld-link`, which is accidentally disallowed by PR#109607.
Similar to previous PRs I've done to change some `IsCLMode` checks to
`isWindowsMSVCEnvironment`.
I stumbled into this one accidentally last week. I did some greps and I
think this is the last one for now. All the remaining `IsCLMode` checks
are only valid for the cl driver mode.
For the `*-windows-msvc` target MSVC link.exe and lld are supported. LTO
isn't supported with MSVC link.exe and so we error when lto is enabled
but MSVC link.exe is being used. However we only error if the driver
mode is cl.
If we are using the clang driver with the `*-windows-msvc` target then
ensure an error is also emitted when LTO and MSVC link.exe are used
together.
Similar reasoning as this PR:
https://github.com/llvm/llvm-project/pull/107177
`-fms-volatile` should be set by default for x86 targets as long as the
triple is `*-windows-msvc`.
The driver mode shouldn't dictate the triple when targeting msvc
compatibility.
Allow `-fjmc` to be used if the target triple is targeting msvc,
`*-windows-msvc`, irrelevant of the driver mode used.
In general the driver mode shouldn't control the target triple.
Also in our custom build system I am trying to just treat clang as
clang. This is because while the `cl` driver mode emulates msvc
interface quite well there are still a lot of operations that are just
clang specific.
The optimization modes do not map directly from msvc to clang.
Warnings do not map from msvc to clang.
Instead of wrapping options with `/clang:` when targeting `clang-cl.exe`
it is just easier to target the clang driver always irrelevant of the
target triple.
From looking at the rest of code and from my own understanding, the
driver mode is supposed to be independent of MSVC compatibility when the
target triple is `*-windows-msvc`.
Therefore strict aliasing should be disabled by default when the target
triple is `*-windows-msvc` so code assuming MSVC behaves as expected
when compiled with Clang.
Remove the `-freroll-loops` flag, which has not had any effect since the
migration to the new pass manager. The underlying pass has been removed
entirely in #80972 due to lack of maintenance and known bugs.
Fixes https://github.com/llvm/llvm-project/issues/59065.
Add a clang flag, "-ftrivial-auto-var-init-max-size=" so that clang
skips auto-init a variable if the auto-init memset size exceeds the flag
setting (in bytes). Note that this skipping doesn't apply to
runtime-sized variables like VLA.
Considerations: "__attribute__((uninitialized))" can be used to manually
opt variables out. However, there are thousands of large variables
(e.g., >=1KB, most of them are arrays and used as buffers) in big
codebase. Manually opting them out one by one is not efficient.
The flag -fms-volatile has existed as a -cc1 flag for a while. It also
technically existed as a driver flag, but didn't do anything because it
wasn't wired up to anything in the driver.
This patch adds -fno-ms-volatile, and makes both -fms-volatile and
-fno-ms-volatile work the same way as the cl-mode flags. The defaults
are unchanged (default on for x86 in cl mode, default off otherwise).
Enables or disables verification of the generated LLVM IR.
Users can pass this to turn on extra verification to catch certain types of
compiler bugs at the cost of extra compile time.
This was deprecated in Clang 16 and scheduled for removal in Clang 18.
Time to remove it.
Reviewed By: nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D159373
Otherwise if the default target triple has `HasNativeLLVMSupport() ==
false`, the %clang command will exit with code 1 due to
err_drv_no_linker_llvm_support.
The issue is exposed by 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)
* 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
AIX prefers rejecting certain unimplemented features like
-fprofile-sample-use, making clang_f_opts.c (legacy test file testing
many miscellaneous features) not suitable. We could specify --target=,
but this style change is probably not the best for this legacy file.
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
Fat LTO objects contain both LTO compatible IR, as well as generated
object code. This allows users to defer the choice of whether to use LTO
or not to link-time. This is a feature available in GCC for some time,
and makes the existing -ffat-lto-objects flag functional in the same
way as GCC's.
This patch adds support for that flag in the driver, as well as setting the
necessary codegen options for the backend. Largely, this means we select
the newly added pass pipeline for generating fat objects.
Users are expected to pass -ffat-lto-objects to clang in addition to one
of the -flto variants. Without the -flto flag, -ffat-lto-objects has no
effect.
// Compile and link. Use the object code from the fat object w/o LTO.
clang -fno-lto -ffat-lto-objects -fuse-ld=lld foo.c
// Compile and link. Select full LTO at link time.
clang -flto -ffat-lto-objects -fuse-ld=lld foo.c
// Compile and link. Select ThinLTO at link time.
clang -flto=thin -ffat-lto-objects -fuse-ld=lld foo.c
// Compile and link. Use ThinLTO with the UnifiedLTO pipeline.
clang -flto=thin -ffat-lto-objects -funified-lto -fuse-ld=lld foo.c
// Compile and link. Use full LTO with the UnifiedLTO pipeline.
clang -flto -ffat-lto-objects -funified-lto -fuse-ld=lld foo.c
// Link separately, using ThinLTO.
clang -c -flto=thin -ffat-lto-objects foo.c
clang -flto=thin -fuse-ld=lld foo.o -ffat-lto-objects # pass --lto=thin --fat-lto-objects to ld.lld
// Link separately, using full LTO.
clang -c -flto -ffat-lto-objects foo.c
clang -flto -fuse-ld=lld foo.o # pass --lto=full --fat-lto-objects to ld.lld
Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977
Depends on D146776
Reviewed By: tejohnson, MaskRay
Differential Revision: https://reviews.llvm.org/D146777
Add -fcheck-new and -fno-check-new, from GCC, which make the compiler
not assume pointers returned from operator new are non-null.
Fixes#16931.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D125272
Previously we only accepted the `-fdiagnostics-misexpect-tolerance=` at
CC1, when it should have been handled identically to
`-fdiagnostics-hotness-threshold=`. It should not have been required to
pass this flag w/ `-Xclang` as reported here:
https://reviews.llvm.org/D115907#inline-1440745
Reviewed By: hans, phosek
Differential Revision: https://reviews.llvm.org/D149206
Following the new flow for external object code emission,
provide flags to switch between integrated and external
backend similar to the integrated assembler options.
SPIR-V target is the only user of this functionality at
this point.
This patch also updated SPIR-V documentation to clarify
that integrated object code emission for SPIR-V is an
experimental feature.
Differential Revision: https://reviews.llvm.org/D125679
It (introduced by 556d713c70bfaf58ac18d089883f9c34c581633a) appears to be
related to the removed dragonegg project. In addition, the feature was a bit
misnamed and may lur users to unnecessarily use it.
This relands commit 731347431976509823e38329a96fcbc69fe98cd2.
It failed on Windows/Mac because `-fjmc` is only checked for ELF targets.
Check the flag unconditionally instead and issue a warning for non-ELF targets.
The motivation is to enable the MSVC-style JMC instrumentation usable by a ELF-based
debugger. Since there is no prior experience implementing JMC feature for ELF-based
debugger, it might be better to just reuse existing MSVC-style JMC instrumentation.
For debuggers that support both ELF&COFF (like lldb), the JMC implementation might
be shared between ELF&COFF. If this is found to inadequate, it is pretty low-cost
switching to alternatives.
Implementation:
- The '-fjmc' is already a driver and cc1 flag. Wire it up for ELF in the driver.
- Refactor the JMC instrumentation pass a little bit.
- The ELF handling is different from MSVC in two places:
* the flag section name is ".just.my.code" instead of ".msvcjmc"
* the way default function is provided: MSVC uses /alternatename; ELF uses weak function.
Based on D118428.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D119910
Try to address Windows flakes from d87bdc272ba47b7d9109ff5c7191454ab2ae6fcb
by adding "|| true" as suggested in D110276 so the whole test doesn't
fail when Windows thinks it can't remove the binary.
Try to address Windows flakes from d87bdc272ba47b7d9109ff5c7191454ab2ae6fcb
by using 'rm -f' instead of just 'rm' as discussed in D110276. For example:
http://45.33.8.238/win/46115/step_7.txt
In looking at the disk space used by a ninja check-all, I found that a
few of the largest files were copies of clang and lld made into temp
directories by a couple of tests. These tests were added in D53021 and
D74811. Clean up these copies after usage.
Differential Revision: https://reviews.llvm.org/D110276
GCC supports multiple forms of -falign-loops=.
-falign-loops= is currently ignored in Clang.
This patch implements the simplest but the most useful form where N is a
power of 2.
The underlying implementation uses a `llvm::TargetOptions` option for now.
Bitcode generation ignores this option.
Differential Revision: https://reviews.llvm.org/D106701
Clang diagnostics should not start with a capital letter or use
trailing punctuation (https://clang.llvm.org/docs/InternalsManual.html#the-format-string),
but quite a few driver diagnostics were not following this advice. This
corrects the grammar and punctuation to improve consistency, but does
not change the circumstances under which the diagnostics are produced.
This patch adds a new clang builtin, __arithmetic_fence. The purpose of the
builtin is to provide the user fine control, at the expression level, over
floating point optimization when -ffast-math (-ffp-model=fast) is enabled.
The builtin prevents the optimizer from rearranging floating point expression
evaluation. The new option fprotect-parens has the same effect on
parenthesized expressions, forcing the optimizer to respect the parentheses.
Reviewed By: aaron.ballman, kpn
Differential Revision: https://reviews.llvm.org/D100118
This patch adds a new clang builtin, __arithmetic_fence. The purpose of the
builtin is to provide the user fine control, at the expression level, over
floating point optimization when -ffast-math (-ffp-model=fast) is enabled.
The builtin prevents the optimizer from rearranging floating point expression
evaluation. The new option fprotect-parens has the same effect on
parenthesized expressions, forcing the optimizer to respect the parentheses.
Reviewed By: aaron.ballman, kpn
Differential Revision: https://reviews.llvm.org/D100118
