Class ExpansionContext encapsulates options for search and expansion of
response files, including configuration files. With this change the
directories which are searched for configuration files are also stored
in ExpansionContext.
Differential Revision: https://reviews.llvm.org/D135439
On AIX, `strict-dwarf` defaults to `true`. This patch implement this default behaviour. Additionally, it adds debug tuning tests.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D135908
This patch moves the judgement if the std c++ modules feature is enabled
into the RenderModulesOptions function. It simplify the code a little
bit further more. It also helps further patches.
D121868 provided support for -darwin-target-variant-triple, but the
support for -darwin-target-variant-sdk-version was still missing for
cc1as. These changes build upon the previous and provides such support.
- Extracted the common code to handle -darwin-target-variant-triple and
-darwin-target-variant-sdk-version in the Darwin toolchain to a method
that can be used for both the cc1 and the cc1as job construction.
cc1as does not support some of the parameters that were provided to
cc1, so the same code cannot be used for both.
- Invoke that new common code when constructing a cc1as invocation.
- Parse the new -darwin-target-variant-sdk-version in the cc1as driver.
Apply its value to the MCObjectFileInfo to generate the right values
in the object files.
- Includes two new tests that check that cc1as uses the provided values
in -darwin-target-variant-sdk and that the Clang driver creates the
jobs with the correct arguments.
Differential Revision: https://reviews.llvm.org/D135729
There are currently two options that are used to tell the compiler to perform
unsafe floating-point optimizations:
'-ffast-math' and '-funsafe-math-optimizations'.
'-ffast-math' is enabled by default. It automatically enables the driver option
'-menable-unsafe-fp-math'.
Below is a table illustrating the special operations enabled automatically by
'-ffast-math', '-funsafe-math-optimizations' and '-menable-unsafe-fp-math'
respectively.
Special Operations -ffast-math -funsafe-math-optimizations -menable-unsafe-fp-math
MathErrno 0 1 1
FiniteMathOnly 1 0 0
AllowFPReassoc 1 1 1
NoSignedZero 1 1 1
AllowRecip 1 1 1
ApproxFunc 1 1 1
RoundingMath 0 0 0
UnsafeFPMath 1 0 1
FPContract fast on on
'-ffast-math' enables '-fno-math-errno', '-ffinite-math-only',
'-funsafe-math-optimzations' and sets 'FpContract' to 'fast'. The driver option
'-menable-unsafe-fp-math' enables the same special options than
'-funsafe-math-optimizations'. This is redundant.
We propose to remove the driver option '-menable-unsafe-fp-math' and use
instead, the setting of the special operations to set the function attribute
'unsafe-fp-math'. This attribute will be enabled only if those special
operations are enabled and if 'FPContract' is either 'fast' or set to the
default value.
Differential Revision: https://reviews.llvm.org/D135097
The clang distributed with the Android NDK has defaulted to lld since r22,
so let's update the driver to match.
Differential Revision: https://reviews.llvm.org/D135421
This was reverted because it was breaking when targeting Darwin which
tried to export these symbols which are now hidden. It should be safe
to just stop attempting to export these symbols in the clang driver,
though Apple folks will need to change their TAPI allow list described
in the commit where these symbols were originally exported
f538018562
Bug: https://github.com/llvm/llvm-project/issues/58265
Differential Revision: https://reviews.llvm.org/D135340
On LoongArch, currently neither of "f" and "d" feature is passed from
clang driver to cc1 by default. This means the backend generates code
for soft float.
In order to run programs in current LoongArch machines (hard float
environment) this patch temporarily enables "f" and "d" features.
In future, we should conditionally turn on these features depend on
various clang options, e.g. -mdouble-float, -msingle-float,
-msoft-float and -mfpu.
HIP is installed at /usr or /usr/local on Debin/Fedora,
and the version file is at {root}/share/hip/version.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D135796
To accomplish this, this patch creates an optional list of environment
variable default values to be set by the runtime to allow directly using
the existing runtime implementation of FORT_CONVERT for I/O conversions.
When -lxxx is specified, if there happens to have a directory or
file with name xxx, clang will not look up libxxx.a, but will
try to unbundle xxx instead.
Reviewed by: Saiyedul Islam, Artem Belevich
Differential Revision: https://reviews.llvm.org/D135724
This patch teaches `clang` to use the prefix `-bplugin_opt:` (instead of `-plugin-opt`) on AIX, when passing plugin options to the linker. This patch follows https://reviews.llvm.org/D134668.
We put the code that decides what plugin option prefix to use at the top of the function `tools::addLTOOptions`. The plugin option prefix, the mcpu prefix, and the opt level prefix are different on AIX. We thought about choosing the strings in a function that reads the linker name and the target triple, or we could push the logic into different derived `ToolChain` classes. But this logic would not be used anywhere else, so these alternatives looked too complicated for what they did. Therefore we are doing it the current way. That said, I am all ears for suggestions to improve this code!
Subsequent code uses the `PluginOptPrefix` variable consistently instead of the hardcoded `-plugin-opt`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D134820
If an invalid architecture is set we currently return an empty string.
This will cause the offloading toolchain to continue to be built and
hit an assertion elsewhere due to the invalid architecture. This patch
fixes that so we now correctly exit.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D135791
The Offloading toolchain currently has two methods for construction the
requires actions. The "new" driver and the old `OffloadActionBuilder`.
Using either one is mutually exclusive, so we should not initialize this
when using the new driver. This was causing some error messages to be
printed multiple times because we were checking them in both the old and
the new driver.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D135715
Summary:
A previous patch ensured that we can't use `-foffload-lto` with CUDA in
non-RDC mode. This did not correctly check for if we were actually
offloading to CUDA so it ended up preventing us from using LTO for
OpenMP.
Summary:
This option forwards a clang flag with a `-no` variant to the Clang
compiler. It should use the `hasFlag` so it works properly when the
option is overridden.
Currently baremetal driver adds <sysroot>/include/c++/v1
for libc++ headers. However on ChromeOS, all include files
are inside <sysroot>/usr/include. So add
<sysroot>/usr/include/c++/v1 if it exists in baremetal driver.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D134478
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
The new driver supports LTO for RDC-mode compilations. However, this was
not correctly handled for non-LTO compilations. HIP can handle this as
it is fed to `lld` which will perform the LTO itself. CUDA however would
require every work which is wholly useless in non-RDC mode so it should
report an error.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D135305
Remove the ability to disable opaque pointers by default in clang.
It is still possible to explicitly disable them via cc1
-no-opaque-pointers.
Differential Revision: https://reviews.llvm.org/D135259
In HIP a library is usually compiled with default target ID e.g. gfx906 so that
it can be used in all GPU configurations. The bitcode is saved in bundled
bitcode with gfx906 in entry ID.
In runtime compilation, a HIP program is compiled with a target ID matching
the GPU configuration, e.g. gfx906:xnack-. This program needs to link with
a library bundled bitcode with target ID gfx906.
For example:
clang --offload-arch=gfx906 -o lib.o lib.hip
clang --offload-arch=gfx906:xnack- program.hip lib.o
This common use case requires that clang-offlod-bundler to be able to extract
entry with compatible target ID, e.g. extracting an gfx906 entry when requesting
gfx906:xnack-.
Currently clang-offload-bundler only allow extracting entry with exact match
of target ID. This patch relaxes that so that it can extract entries with compatible
target ID.
Reviewed by: Artem Belevich, Saiyedul Islam
Differential Revision: https://reviews.llvm.org/D134546
This reverts commit 43fe6f7cc3.
Reverting this as CI breaks.
To reproduce, run check-flang, and it will fail with an error saying
.../lib/Bye.so not found in pass-plugin.f90
Add the -fpass-plugin option to flang which dynamically loads LLVM passes from the
shared object passed as the argument to the flag. The behavior of the option is
designed to replicate that of the same option in clang and thus has the same
capabilities and limitations.
- Multiple instances of -fpass-plugin=path-to-file can be specified and each of the
files will be loaded in that order.
- The flag can be passed to both flang-new and flang-new -fc1.
Differential Revision: https://reviews.llvm.org/D129156
The linker requires at least a "major.minor" for the SDK version, so it will fail when we don't have
a minor version in the case we don't actually have an SDK info.
Add support for a CLANG_NO_DEFAULT_CONFIG envvar that works like
the --no-default-config option when set to a non-empty value. Use it
to disable loading system configuration files during the test suite
runs.
Configuration files can change the driver behavior in extensive ways,
and it is neither really possible nor feasible to account for or undo
the effects of even the most common configuration uses. Therefore,
the most reasonable option seems to be to ignore configuration files
while running the majority of tests (with the notable exception of tests
for configuration file support).
Due to the diversity of ways that %clang is used in the test suite,
including using it to copy or symlink the clang executable, as well to
call -cc1 and -cc1as modes, it is not feasible to pass the explicit
options to disable config loading either. Using an environment variable
has the advantage of being easily applied across the test suite
and easily unset for default configuration file loading tests.
Differential Revision: https://reviews.llvm.org/D134905
D103221 changed HIP's default to C++14, removing the driver logic to
force it into a different std.
Change-Id: I9f5220a7456687039b0bd3b3574f3124d3cc7665
Differential Revision: https://reviews.llvm.org/D134314
Change-Id: I40513f2ebe93ee53ea95c8bb3cc704487d970263
Change the default config file loading logic to be more flexible
and more readable at the same time. The new algorithm focuses on four
locations, in order:
1. <triple>-<mode>.cfg using real driver mode
2. <triple>-<mode>.cfg using executable suffix
3. <triple>.cfg + <mode>.cfg using real driver mode
4. <triple>.cfg + <mode>.cfg using executable suffix
This is meant to preserve reasonable level of compatibility with
the existing use, while introducing more flexibility and making the code
simpler. Notably:
1. In this layout, the actual target triple is normally respected,
and e.g. in `-m32` build the `x86_64-*` configs will never be used.
2. Both real driver mode (preferable) and executable suffix are
supported. This permits correctly handling calls with explicit
`--driver-mode=` while at the same time preserving compatibility
with the existing code.
3. The first two locations provide users with the ability to override
configuration per specific target+mode combinaton, while the next two
make it possible to independently specify per-target and per-mode
configuration.
4. All config file locations are applicable independently of whether
clang is started via a prefixed executable, or bare `clang`.
5. If the target is not explicitly specified and the executable prefix
does not name a valid triple, it is used instead of the actual target
triple for backwards compatibility.
This is particularly meant to address Gentoo's use case for
configuration files: to configure the default runtimes (i.e. `-rtlib=`,
`-stdlib=`) and `--gcc-install-dir=` for all the relevant drivers,
as well as to make it more convenient for users to override `-W` flags
to test compatibility with future versions of Clang easier.
Differential Revision: https://reviews.llvm.org/D134337
There are lots of options interacting in complex ways here, and when moving to
`getDefaultUnwindTableLevel` I had refactored this and changed behaviour in
some cases. So this reverts the basic structure of the logic back to the
original, while leaving the hook in the new style.
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
This cc1 option -fallow-half-arguments-and-returns allows __fp16 to be
passed by argument and returned, without giving an error. It is
currently always enabled for Arm and AArch64, by forcing the option in
the driver. This means any cc1 tests (especially those needing
arm_neon.h) need to specify the option too, to prevent the error from
being emitted.
This changes it to a target option instead, set to true for Arm and
AArch64. This allows the option to be removed. Previously it was implied
by -fnative_half_arguments_and_returns, which is set for certain
languages like open_cl, renderscript and hlsl, so that option now too
controls the errors. There were are few other non-arm uses of
-fallow-half-arguments-and-returns but I believe they were unnecessary.
The strictfp_builtins.c tests were converted from __fp16 to _Float16 to
avoid the issues.
Differential Revision: https://reviews.llvm.org/D133885
This eagerly reports use of undef values when passed to noundef
parameters or returned from noundef functions.
This also decreases binary sizes under msan.
To go back to the previous behavior, pass `-fno-sanitize-memory-param-retval`.
Reviewed By: vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D134669
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
The following three static functions in `clang/lib/Driver/ToolChains/CommonArgs.cpp`
```
static void renderRpassOptions(...)
static void renderRemarksOptions(...)
static void renderRemarksHotnessOptions(...)
```
use `--plugin-opt` for the plugin option prefix, while the function `tools::addLTOOptions` uses `-plugin-opt`. This patch makes sure that we only use `-plugin-opt` (single dash) everywhere. It is not clear to me that why we decided to use `--plugin-opt` in https://reviews.llvm.org/D85810. If using `--plugin-opt` is intended, I'd love to hear the reason and I will close this patch.
We intend to followup this patch with a few other patches that teach `clang` to pass plugin options to the AIX linker, which uses a different prefix (`-bplugin_opt:`).
Reviewed By: w2yehia
Differential Revision: https://reviews.llvm.org/D134668
Serge Pavlov