This patch moves the CommonArgs utilities into a location visible by the
Frontend Drivers, so that the Frontend Drivers may share option parsing
code with the Compiler Driver. This is useful when the Frontend Drivers
would like to verify that their incoming options are well-formed and
also not reinvent the option parsing wheel.
We already see code in the Clang/Flang Drivers that is parsing and
verifying its incoming options. E.g. OPT_ffp_contract. This option is
parsed in the Compiler Driver, Clang Driver, and Flang Driver, all with
slightly different parsing code. It would be nice if the Frontend
Drivers were not required to duplicate this Compiler Driver code. That
way there is no/low maintenance burden on keeping all these parsing
functions in sync.
Along those lines, the Frontend Drivers will now have a useful mechanism
to verify their incoming options are well-formed. Currently, the
Frontend Drivers trust that the Compiler Driver is not passing back junk
in some cases. The Language Drivers may even accept junk with no error
at all. E.g.:
`clang -cc1 -mprefer-vector-width=junk test.c'
With this patch, we'll now be able to tighten up incomming options to
the Frontend drivers in a lightweight way.
---------
Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
The PR is to generalize the re-use of the `compilerRT` code of adding
the path of `libflang_rt.runtime.a (so)` from AIX and LoP only to all
platforms via a new function `addFlangRTLibPath`.
It also added `-static-libflangrt` and `-shared-libflangrt` compiler
options to allow users choosing which `flang-rt` to link to. It defaults
to shared `flang-rt`, which is consistent with the linker behavior,
except on AIX, it defaults to static.
Also, PR #134320 exposed an issue in PR #131041 that the the overriding
`addFortranRuntimeLibs` is missing the link to `libquadmath`. This PR
also fixed that and restored the test case that PR #131041 broke.
This PR is to improve the driver code to build `flang-rt` path by
re-using the logic and code of `compiler-rt`.
1. Moved `addFortranRuntimeLibraryPath` and `addFortranRuntimeLibs` to
`ToolChain.h` and made them virtual so that they can be overridden if
customization is needed. The current implementation of those two
procedures is moved to `ToolChain.cpp` as the base implementation to
default to.
2. Both AIX and PPCLinux now override `addFortranRuntimeLibs`.
The overriding function of `addFortranRuntimeLibs` for both AIX and
PPCLinux calls `getCompilerRTArgString` => `getCompilerRT` =>
`buildCompilerRTBasename` to get the path to `flang-rt`. This code
handles `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` setting. As shown in
`PPCLinux.cpp`, `FT_static` is the default. If not found, it will search
and build for `FT_shared`. To differentiate `flang-rt` from `clang-rt`,
a boolean flag `IsFortran` is passed to the chain of functions in order
to reach `buildCompilerRTBasename`.
Add support for existing -rpath option to AIX. Prior to this PR,
if -rpath is passed on AIX it gets passed to the linker and crashes as
the linker on AIX cannot process it.
In PowerPC ABI, a few initial arguments are passed through registers,
but their places in parameter save area are reserved, arguments passed
by memory goes after the reserved location.
For debugging purpose, we may want to save copy of the pass-by-reg
arguments into correct places on stack. The new option achieves by
adding new function level attribute and make argument lowering part
aware of it.
`#pragma mc_func` is an IBM XL feature that should be replaced by inline
assembly. This PR adds an option `-ferr-pragma-mc-func-aix` to detect
uses of `#pragma mc_func` and reports an error if the option is in
effect. If `-fno-err-pragma-mc-func-aix` is in effect, `#pragma mc_func`
is ignored even if `-Werror=unknown-pragmas` is in effect.
Some `libc++` LIT test cases and user code define their own version of
`operator delete` that are not sized. With `-fno-sized-deallocation`,
destructors call the non-sized `operator delete` and it will be resolved
to the user defined version. However, with `-fsized-deallocation`,
destructors will call the sized `operator delete` which will be resolved
to the weak definition in `libc++abi` because the user code does not
define the corresponding sized version. The `libc++abi` sized `operator
delete` in turn calls the non-sized version of `operator delete` of the
same shared object inside `libc++abi` instead of the user defined
version on AIX because runtime linking is not the default for AIX and
therefore, fails the tests or user code. This patch sets
`-fno-sized-deallocation` as the default for AIX if neither
`-fsize-deallocation` nor `-fno-sized-deallocation` is explicitly set,
similar to what is done for ZOS.
This patch adds support for toc-data for 64-bit large code-model on AIX.
The sequence ADDIStocHA8/ADDItocL8 is used to access the data directly
from the TOC.
When emitting the instruction ADDIStocHA8, we check if the symbol has
toc-data attribute before creating a toc entry for it. When emitting the
instruction ADDItocL8, we use the LA8 instruction to load the address.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
13 under clang/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
4ddd4ed7fe15a added a use of std::set without including it. With some
recent libc++, std::set isn't included transitively causing build
failures.
Add explicit include.
Failure with testcase toc-conf.c observed when building with
LLVM_REVERSE_ITERATION=ON.
Changing from using llvm::StringSet to std::set<llvm:StringRef> to
ensure iteration order is deterministic. Note: the functionality of the
feature does not require a specific iteration order, however, this will
allow testing to be consistent.
From llvm docs:
The advantages of std::set are that its iterators are stable (deleting
or inserting an element from the set does not affect iterators or
pointers to other elements) and that iteration over the set is
guaranteed to be in sorted order.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```
It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```
I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.
Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.
Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.
Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159173
https://reviews.llvm.org/D157280 enabled `-fprofile-update` for `-fprofile-generate`, but omitted adding `-latomic` to the linker command on AIX. This omission causes linking to fail due to an undefined symbol. This patch fixes the link error.
Reviewed By: w2yehia
Differential Revision: https://reviews.llvm.org/D159137
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
so that we report `unsupported option '-G' for target ...` on
unsupported targets (most targets).
This error is tested by one target in aix-err-options.c.
Follow-up to D89897 and D90063.
clang/lib/Driver/ToolChains/Clang.cpp has a lot of fragments like the following:
```
if (const Arg *A = Args.getLastArg(...)) {
if (Triple is xxx)
A->render(Args, CmdArgs);
else
D.Diag(diag::err_drv_unsupported_opt_for_target) << ...;
}
```
The problem is more apparent with a recent surge of AIX-specific options.
Introduce the TargetSpecific flag so that we can move the target-specific
options to ToolChains/*.cpp and ToolChains/Arch/*.cpp and overload the
warn_drv_unused_argument mechanism to give an err_drv_unsupported_opt_for_target
error.
Migrate -march=/-mcpu= and some AIX-specific options to use this simplified pattern.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D151590
This patch adds clang options `-mxcoff-roptr` and `-mno-xcoff-roptr` to specify storage locations for constant pointers on AIX.
When the `-mxcoff-roptr` option is in effect, constant pointers, virtual function tables, and virtual type tables are placed in read-only storage. When the `-mno-xcoff-roptr` option is in effect, pointers, virtual function tables, and virtual type tables are placed are placed in read/write storage.
This patch depends on https://reviews.llvm.org/D144189.
Reviewed By: hubert.reinterpretcast, stephenpeckham
Differential Revision: https://reviews.llvm.org/D144190
The -mxcoff-build-id=0xHEXSTRING option is an alternative to the
--build-id=0xHEXSTRING linker option that is not currently available in
the AIX linker.
If HEXSTRING is an odd number of hex digits then a '0' character is prepended.
The characters ':' and '-' are not allowed (unlike the GNU linker option).
The given build-id will be saved in the string table of the loader section.
A subsequent commit will teach the profile runtime to read and use the embedded id.
Reviewed By: daltenty, qiongsiwu1, stephenpeckham
Differential Revision: https://reviews.llvm.org/D146431
when certain flags are specified, the Crt0 object files are not linked.
However, the logic for determining which files will always run. This
patch moves that logic so that the basename is only determined if it is
needed.
Differential Revision: https://reviews.llvm.org/D146443
On AIX, libraries are still being linked when `-r` is passed to the driver. This patch corrects this error.
Differential Revision: https://reviews.llvm.org/D145899
The current implementation of `-p` does not claim the argument once it
is passed. Since it pushes `-pg` directly, it is only ever referred to
again when linking. As a result, when compiling with `-S`, the compiler
warns that `-p` goes unused even though that is not the case.
With this patch, if both `-p` and `-pg` are passed, the argument that is
passed second will take precedence. `-p` will still throw an error on
unsupported platforms, regardless of precedence.
This revision includes a test case, which has been placed in
`clang/test/Driver/zos-profiling-error.c`. As a result,
`zos-profiling-error.c` has been renamed to `ibm-profiling.c`. This
revision also passes `clang/test/Driver/aix-ld.c`.
Differential Revision: https://reviews.llvm.org/D145021
The current implementation of `-p` does not claim the argument once it
is passed. Since it pushes `-pg` directly, it is only ever referred to
again when linking. As a result, when compiling with `-S`, the compiler
warns that `-p` goes unused even though that is not the case.
With this patch, if both `-p` and `-pg` are passed, the argument that is
passed second will take precedence. `-p` will still throw an error on
unsupported platforms, regardless of precedence.
This revision includes a test case, which has been placed in
`clang/test/Driver/zos-profiling-error.c`. As a result,
`zos-profiling-error.c` has been renamed to `ibm-profiling.c`. This
revision also passes `clang/test/Driver/aix-ld.c`.
Differential Revision: https://reviews.llvm.org/D145021
This patch enables `-p` functionality into Clang on AIX and Linux
To create parity with GCC.
The purpose of the `-p` flag is similar to that of `-pg`, but the
results are analyzed with the `prof` tool as opposed to the `gprof` tool.
More details can be found in this RFC post:
https://discourse.llvm.org/t/rfc-add-p-driver-support-to-clang/66013?u=francii
On AIX, compiling with `-p` links against `mcrt0.o`
and produces a mon.out file analyzed with the `prof` tool,
while `-pg` links against `gcrt0.o` and produces a `gmon.out`file
analyzed with the `gprof` tool. The differences are therefore
only a concern when linking, so calling `-p` will push `-pg` to cc1.
An AIX test for `-p` already exists, and I recently
another test was added here:
dc9846ce98
As such, there is no AIX test case attached to this patch.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D137753
flang-new encounters an issue where its unable to invoke itself because the
install directory was missing from the program paths on AIX.
Reviewed By: w2yehia
Differential Revision: https://reviews.llvm.org/D140628
Summary:
This patch adds OpenMP runtime to the linker command line if -fopenmp is specifed for AIX.
Reviewed by: daltenty
Differential Revision: https://reviews.llvm.org/D141862
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
On AIX, profiled system libraries are stored at `/lib/profiled` and
`/usr/lib/profiled`. When compiling with `-pg`, we want to link against
libraries in those directories. This PR modifies the AIX toolchain to
add those directories to the linker search paths.
Differential Review: https://reviews.llvm.org/D137375
1) Use a static array of pointer to retain the dummy vars.
2) Associate liveness of the array with that of the runtime hook variable
__llvm_profile_runtime.
3) Perform the runtime initialization through the runtime hook variable.
4) Preserve the runtime hook variable using the -u linker flag.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D136192
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
Summary:
Some of code in the patch are contributed by David Tenty.
1. We currently only check driver Wl options and don't check for the plain -b, -Xlinker or other options which get passed through to the linker when we decide whether to run llvm-nm --export-symbols, so we may run it in situations where we wouldn't if the user had used the equivalent -Wl, prefixed options. If we run the export list utility when the user has specified an export list, we could export more symbols than they intended.
2. Add a new functionality to allow redirecting the stdin, stdout, stderr of individual Jobs, if redirects are set for the Job use them, otherwise fall back to the global Compilation redirects if any.
Reviewers: David Tenty, Fangrui Song, Steven Wan
Differential Revision: https://reviews.llvm.org/D119147
These headers used to be guarded only on PowerPC64 Linux or FreeBSD, but
they can also be enabled for AIX OS target since it's big-endian ready.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D129461
Based on the discussion at [1], this patch adds a Clang flag called
-fexperimental-library that controls whether experimental library
features are provided in libc++. In essence, it links against the
experimental static archive provided by libc++ and defines a feature
that can be picked up by libc++ to enable experimental features.
This ensures that users don't start depending on experimental
(and hence unstable) features unknowingly.
[1]: https://discourse.llvm.org/t/rfc-a-compiler-flag-to-enable-experimental-unstable-language-and-library-features
Differential Revision: https://reviews.llvm.org/D121141
This patch switches the PGO implementation on AIX from using the runtime
registration-based section tracking to the __start_SECNAME/__stop_SECNAME
based. In order to enable the recognition of __start_SECNAME/__stop_SECNAME
symbols in the AIX linker, the -bdbg:namedsects:ss needs to be used.
Reviewed By: jsji, MaskRay, davidxl
Differential Revision: https://reviews.llvm.org/D124857
