Summary:
We want to pass these GPU libraries by default if a certain offloading
toolchain is loaded for OpenMP. Previously I parsed this from the
arguments because it's only available in the compilation. This doesn't
really work for `native` and it's extra effort, so this patch just
passes in the `Compilation` as an extr argument and uses that. Tests
should be unaffected.
The flang driver was silently ignoring the `main()` function in
`Fortran_main.a` for entry into the Fortran program unit if an external
`main()` as supplied (e.g., via cross-language linkage with Fortran and
C/C++). This PR fixes this by making sure that the linker always pulls
in the `main()` definition from `Fortran_main.a` and consequently fails
due to multiple definitions of the same symbol if another object file
also has a definition of `main()`.
This patch uses the added --dependent-lib support to add the relevant
runtimes on MSVC targets as `/DEFAULTLIB:` sections in the object file
rather than on the link line. This should help CMake support for flang
on Windows.
Fixes#63741Fixes#68017
-no-pie[1]/-nopie is rarely used and among the rare uses almost
everwhere uses -no-pie, since GCC does not recognize -nopie.
However, OpenBSD seems to use -nopie. Therefore, make -nopie specific
to OpenBSD to prevent newer ToolChains (Solaris, SerenityOS) from cargo
culting and copying -nopie.
[1]: https://reviews.llvm.org/D35462
Currently flang's runtime libraries are only built for the specific CRT
that LLVM itself was built against. This patch adds the cmake logic for
building a separate runtime for each CRT configuration and adds a flag
for selecting a CRT configuration to link against.
- FreeBSD removed big-endian arm with 12.0.
- OpenBSD never had big-endian arm support. I added it just in case, but it has
never been used.
- Remove sparcel bits. It was sprinkled in a few places but it will never be a
thing.
- Remove 32-bit sparc bits for FreeBSD. FreeBSD has never had 32-bit sparc
support.
- Remove sparc64 IAS test as support was enabled across the board awhile ago.
The entry point symbol handling matches our GCC link spec..
```%{!shared:%{!nostdlib:%{!r:%{!e*:-e __start}}}}```
Remove usage of -Bdynamic as it is the default for the linker anyway.
Came up in discussion here https://github.com/llvm/llvm-project/pull/65644
-Z is an Apple ld64 option. ELF linkers don't recognize -Z, except
OpenBSD which patched GNU ld to add -Z for zmagic (seems unused)
> -Z Produce 'Standard' executables, disables Writable XOR Executable
features in resulting binaries.
Some `ToolChain`s have -Z due to copy-and-paste mistakes.
Most ArgList member functions use the modern functionName style while some like
AddAllArgs use the legacy FunctionName style. These uses are mostly linker
options which have been modified recently to fix duplicate -e issues, so just
update these call sites.
Following the lead of the Linux code, this patch passes the `ld -z` options
as two separate args on Solaris, improving legibility. For lack of a
variadic `std::push_back`, `getAsNeededOption` had to be changed to
`addAsNeededOption`, matching other `add*Options` functions, changing
callers accordingly. The additional args are also used in a WIP revision
of the Solaris GNU ld patch D85309 <https://reviews.llvm.org/D85309>, which
will allow runtime selection of the linker to use.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D158955
-e has the LinkerInput flag (commit fcf8ada18f9cfb1261262e4b0399ae9ab40451f8)
and is rendered by AddLinkerInputs. We should remove duplicate rendering (e.g.,
`Args.AddAllArgs(CmdArgs, options::OPT_e)`).
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
No behavior change as GNU ld/gold/ld.lld ignore --dynamic-linker in -r mode.
This change makes the intention clearer as we already suppress --dynamic-linker
for -shared, -static, and -static-pie.
Reviewed by: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D129714
Clang uses runtime libraries for some advanced features like
sanitizers. Different systems have different preferences about file
placement. OpenBSD with this change will use this name for ASan:
/usr/lib/clang/15.0.0/lib/libclang_rt.asan.a
Already committed to OpenBSD repository then amended to cover the
case of development tree.
Differential Revision: https://reviews.llvm.org/D109051
Now prints the list of known archs. This requires plumbing a Driver
arg through a few functions.
Also add two more convenience insert() overlods to StringMap.
Differential Revision: https://reviews.llvm.org/D109105
Object of class `Command` contains various properties of a command to
execute, but output file was missed from them. This change adds this
property. It is required for reporting consumed time and memory implemented
in D78903 and may be used in other cases too.
Differential Revision: https://reviews.llvm.org/D78902
If not overridden, AddClangSystemIncludeArgs's implementation is empty, so by
default, no system include args are added to the Clang driver. This means that
invoking Clang without the frontend must include a manual -I/usr/include flag,
which is inconsistent behavior. Therefore, override and implement this method
to match. Some boilerplate is also borrowed for handling of the other driver
flags.
While we are here, also override and enable HasNativeLLVMSupport.
Patch by: 3405691582 (dana koch)
Differential Revision: https://reviews.llvm.org/D86412
specified at Command creation, rather than as part of the Tool.
This resolves the hack I just added to allow Darwin toolchain to vary
its level of support based on `-mlinker-version=`.
The change preserves the _current_ settings for response-file support.
Some tools look likely to be declaring that they don't support
response files in error, however I kept them as-is in order for this
change to be a simple refactoring.
Differential Revision: https://reviews.llvm.org/D82782
Very few ELF platforms still use .ctors/.dtors now. Linux (glibc: 1999-07),
DragonFlyBSD, FreeBSD (2012-03) and Solaris have supported .init_array
for many years. Some architectures like AArch64/RISC-V default to
.init_array . GNU ld and gold can even convert .ctors to .init_array .
It makes more sense to flip the CC1 default, and only uses
-fno-use-init-array on platforms that don't support .init_array .
For example, OpenBSD did not support DT_INIT_ARRAY before Aug 2016
(86fa57a279)
I may miss some ELF platforms that still use .ctors, but their
maintainers can easily diagnose such problems.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D71393
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
