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.
Remove the llvm_unreachable from getSolarisLibSuffix(). The code path is
reachable. In the case of an unsupported architecture we're not worrying
about trying to actually find the library paths, and I don't think it
makes sense for the Driver to crash.
Fixes#58334
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.
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.
As discussed in [[Driver] Link Flang runtime on Solaris](https://github.com/llvm/llvm-project/pull/65644), `clang -r`
incorrectly passes both `-Bdynamic` and `-e _start` to `ld` which lets the linker choke.
This patch fixes this, omitting `-Bdynamic` completely which is the linker default.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
I noticed that `flang-new` cannot link Fortran executables on Solaris since the runtime libs are missing.
This patch fixes this, following `Gnu.cpp`. The `linker-flags.f90` testcase is augmented to test for this,
renaming the `GNU` label to `UNIX` so it can be reused. Also use the current form `--target=` in the tests
and join the `-l` lines in the test for readibility.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
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.
As noticed in D158846, the Solaris driver deviates from other targets in
that it links every executable with `-lm`, but doesn't for shared
objects. For C code, this is unnecessary, while for C++ `libm` is always
needed, even for shared objects.
This patch fixes this by following the `Gnu.cpp` precedent. It adjusts
the `solaris-ld.c` test accordingly, adding some more tests.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
`clang -fno-integrated-as` doesn't currently work on Solaris: it doesn't
even select between 32 and 64-bit objects. Besides, Solaris has both the
native assembler (`/usr/bin/as`) and the GNU assembler (`/usr/bin/gas`
resp. `/usr/gnu/bin/as`). The native sparc and x86 assemblers aren't
compatible with `clang`'s assembler syntax to varying degrees, and the
command line options for `as` and `gas` are completely different.
Therefore this patch chooses to always use `gas` on Solaris, using
`gnutools::Assembler::ConstructJob` to pass the correct options.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
`clang` currently links `libgcc_s` unconditionally on Solaris, which is
unnecessary.
This patch wraps it in `-z ignore`/`-z record` instead.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
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
`clang` currently lacks PIE support on Solaris. This patch fixes this,
also linking with `crtbeginS.o` and `crtendS.o` for `-pie` and `-shared`.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D158206
As detailed in Issue #64126, several asan tests `FAIL` due to a cycle in
`AsanInitInternal`. This can by avoided by disabling lazy binding with `ld
-z now`.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D156325
-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)`).
Functions instrumented with -fsanitize=function have two words before
the function label: a signature and a RTTI proxy.
Instrumented call sites check the signature first to skip checks
for uninstrumented callees.
The code is generic and works for all targets supporting C++ RTTI.
Change clangDriver to allow all targets. Add tests for Armv8.5
Branch Target Identification and `-fpatchable-function-entry=`.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D148573
`Flang :: Driver/fast_math.f90` `FAIL`s on Solaris because `crtfastmath.o`
is missing from the link line.
This patch adds it as appropriate.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D141596
This is the driver part of D91605 <https://reviews.llvm.org/D91605>, a
workaround to allow direct calls to `__tls_get_addr` on Solaris/amd64.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D119829
Even after D86621 <https://reviews.llvm.org/D86621>, `clang -m32` on
Solaris/sparcv9 doesn't inline atomics with 8-byte operands, unlike `gcc`.
This leads to many link failures in the testsuite (undefined references to
`__atomic_load_8` and `__sync_val_compare_and_swap_8`. Until a proper
codegen fix can be implemented, this patch works around the first of those
by linking with `-latomic`.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D118021
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
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
For each absolute path given to C_INCLUDE_DIRS, we want it to be added
as-is to the include search path. Relative paths should be prefixed
with the sysroot.
Thanks to Marco Hinz for the patch.
Differential Revision: https://reviews.llvm.org/D69221
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
Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and
x86, 32 and 64-bit.
It turned out that this is due to different behaviour of logb depending on the C
standard compiled for, as documented on logb(3M):
RETURN VALUES
Upon successful completion, these functions return the exponent of x.
If x is subnormal:
o For SUSv3-conforming applications compiled with the c99 com-
piler driver (see standards(7)), the exponent of x as if x
were normalized is returned.
o Otherwise, if compiled with the cc compiler driver, -1022,
-126, and -16382 are returned for logb(), logbf(), and
logbl(), respectively.
Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those.
The following patch fixes this by following what gcc does, as corrected some time ago in
Fix use of Solaris values-Xc.o (PR target/40411)
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html.
Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
Differential Revision: https://reviews.llvm.org/D64793
llvm-svn: 367866
UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently
FAILs on Solaris/x86_64:
clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11'
AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only),
which is what this patch does, together with updating another testcase.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64488
llvm-svn: 367351
I noticed that clang currently passes --dynamic-linker to ld. This has been the case
since Solaris 11 support was added initially back in 2012 by David Chisnall (r150580).
I couldn't find any patch submission, let alone a justification, for this, and it seems
completely useless: --dynamic-linker is a gld compatibility form of the option, the
native option being -I. First of all, however, the dynamic linker passed is simply the
default, so there's no reason at all to specify it in the first place.
This patch removes passing the option and adjusts the affected testcase accordingly.
Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64493
llvm-svn: 366202
As explained in https://reviews.llvm.org/D63601, there's no point using clang_rt.sancov_{begin,end}
on Solaris any longer.
This companion patch to the above removes their use from the driver.
Tested on amd64-pc-solaris2.11
Differential Revision: https://reviews.llvm.org/D63602
llvm-svn: 365396
Disabled by default as this is still an experimental feature.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D59221
llvm-svn: 358285
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
Summary:
During make check-all on Solaris, I see several instances of this warning:
clang-6.0: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
Since Solaris 10, libpthread has been folded into libc, so there's nothing to do. gcc
just ignores -pthread here. Darwin claims the option to silence the warning, and
this patch follows that lead.
Reviewers: rsmith, fedor.sergeev
Reviewed By: fedor.sergeev
Subscribers: cfe-commits, fedor.sergeev
Differential Revision: https://reviews.llvm.org/D41242
llvm-svn: 324344
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
Projects that want to statically link their own C++ standard library currently
need to pass -nostdlib or -nodefaultlibs, which also disables linking of the
builtins library, -lm, and so on. Alternatively, they could use `clang` instead
of `clang++`, but that already disables implicit addition of -lm on some
toolchains.
Add a dedicated flag -nostdlib++ that disables just linking of libc++ /
libstdc++. This is analogous to -nostdinc++.
https://reviews.llvm.org/D35780
llvm-svn: 308997
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
