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
Using noexcept multilib with -fno-exceptions can lead to significant
space savings when statically linking libc++abi because we don't need
all the unwinding and demangling code.
When compiling with ASan, we already get a lot of overhead from the
instrumentation itself, when statically linking libc++abi, that overhead
is even larger.
Having the noexcept variant for ASan can help significantly, we've seen
more than 50% size reduction in our system image, which offsets the cost
of having to build another multilib.
Differential Revision: https://reviews.llvm.org/D64140
llvm-svn: 365994
This is a follow up to r361432, changing the layout of per-target
runtimes to more closely resemble multiarch. While before, we used
the following layout:
[RESOURCE_DIR]/<target>/lib/libclang_rt.<runtime>.<ext>
Now we use the following layout:
[RESOURCE_DIR]/lib/<target>/libclang_rt.<runtime>.<ext>
This also more closely resembles the existing "non-per-target" layout:
[RESOURCE_DIR]/lib/<os>/libclang_rt.<runtime>-<arch>.<ext>
This change will enable further simplification of the driver logic
in follow up changes.
Differential Revision: https://reviews.llvm.org/D62469
llvm-svn: 361784
This is a follow up to r361432 and r361504 which addresses issues
introduced by those changes. Specifically, it avoids duplicating
file and runtime paths in case when the effective triple is the
same as the cannonical one. Furthermore, it fixes the broken multilib
setup in the Fuchsia driver and deduplicates some of the code.
Differential Revision: https://reviews.llvm.org/D62442
llvm-svn: 361709
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/$target/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
Summary:
This commit moves the logic for determining system, resource and C++
header search paths from CC1 to the driver. This refactor has already
been made for several platforms, but Darwin had been left behind.
This refactor tries to implement the previous search path logic with
perfect accuracy. In particular, the order of all include paths inside
CC1 and all paths that were skipped because nonexistent are conserved
after the refactor. This change was also tested against a code base
of significant size and revealed no problems.
Reviewers: jfb, arphaman
Subscribers: nemanjai, javed.absar, kbarton, christof, jkorous, dexonsmith, jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61963
llvm-svn: 361278
When compiler-rt is selected as the runtime library for Linux targets
use its crtbegin.o/crtend.o implemenetation rather than platform one
if available.
Differential Revision: https://reviews.llvm.org/D59264
llvm-svn: 359603
This introduces a support for multilibs to Fuchsia driver. Unlike the
existing multilibs that are used primarily for handling different
architecture variants, we use multilibs to handle different variants
of Clang runtime libraries: -fsanitize=address and -fno-exceptions
are the two we support initially. This replaces the existing support
for sanitized runtimes libraries that was only used by Fuchsia driver
and it also refactors some of the logic to allow sharing between GNU
and Fuchsia drivers.
Differential Revision: https://reviews.llvm.org/D61040
llvm-svn: 359360
When setting up library and tools paths when detecting an accompanying GCC
installation only riscv32 was handled. As a consequence when targetting
riscv64 neither the linker nor libraries would be found. This adds handling
and tests for riscv64.
Differential Revision: https://reviews.llvm.org/D53392
Patch by Edward Jones.
llvm-svn: 357699
This is an initial implementation for msp430 toolchain including
-mmcu option support
-mhwmult options support
-integrated-as by default
The toolchain uses msp430-elf-as as a linker and supports msp430-gcc toolchain tree.
Patch by Kristina Bessonova!
Differential Revision: https://reviews.llvm.org/D56658
llvm-svn: 351228
pass in the -target-sdk-version to the compiler and backend
This commit adds support for reading the SDKSettings.json file in the Darwin
driver. This file is used by the driver to determine the SDK's version, and it
uses that information to pass it down to the compiler using the new
-target-sdk-version= option. This option is then used to set the appropriate
SDK Version module metadata introduced in r349119.
Note: I had to adjust the two ast tests as the SDKROOT environment variable
on macOS caused SDK version to be picked up for the compilation of source file
but not the AST.
rdar://45774000
Differential Revision: https://reviews.llvm.org/D55673
llvm-svn: 349380
This adds Hurd toolchain support to Clang's driver in addition
to handling translating the triple from Hurd-compatible form to
the actual triple registered in LLVM.
(Phabricator was stripping the empty files from the patch so I
manually created them)
Patch by sthibaul (Samuel Thibault)
Differential Revision: https://reviews.llvm.org/D54379
llvm-svn: 347833
ray's gcc installation puts C++ headers in PREFIX/include/g++ without
indicating a gcc version at all. Typically this is because the version
is encoded somewhere in PREFIX.
Differential Revision: https://reviews.llvm.org/D53770
llvm-svn: 346802
Some of the test data went missing last time I tried to submit this,
causing the tests to fail when the build did not include libc++.
Original review was https://reviews.llvm.org/D53109.
llvm-svn: 344946
This is part of previous commit [HIP] Replace irif library with hip.amdgcn.bc
Reviewers: yaxunl
Differential Revision: https://reviews.llvm.org/D52673
llvm-svn: 344285
No longer use irif amdgcn library, instead we will use the previous fence functions from new hip.amdgcn.bc bitcode library. Update hip-device-libs.hip test as well.
llvm-svn: 344281
clang-offload-bundler should not be invoked with the unbundling action
when the input file type does not match the action type. For example,
.so files should be unbundled during linking phase and should be linked
only with the host code.
llvm-svn: 343335
types."
It reverts commit r342991 + several other commits intended to fix the
tests. Still have some failed tests, need to investigate it.
llvm-svn: 343002
clang-offload-bundler should not be invoked with the unbundling action
when the input file type does not match the action type. For example,
.so files should be unbundled during linking phase and should be linked
only with the host code.
llvm-svn: 342991
Previously we only used target triple as provided which matches the
GCC behavior, but it also means that all clients have to be consistent
in their spelling of target triples since e.g. x86_64-linux-gnu and
x86_64-unknown-linux-gnu will result in Clang driver looking at two
different paths when searching for runtime libraries.
Unfortunatelly, as it turned out many clients aren't consistent in
their spelling of target triples, e.g. many Linux distributions use
the shorter spelling but config.guess and rustc insist on using the
normalized variant which is causing issues. To avoid having to ship
multiple copies of runtimes for different triple spelling or rely on
symlinks which are not portable, we should also check the normalized
triple when constructing paths for multiarch runtimes.
Differential Revision: https://reviews.llvm.org/D50547
llvm-svn: 340471
In r339807, I broke linking the builtins libraries for simulator targets, which itself was bad, but turns out it was all completely untested and marked with FIXME in the test suite.
This fixes all the test cases so they actually work, and fixes the bug I introduced in r339807.
llvm-svn: 339829
This change causes issues with distributed build systems, which may only
have compiler binaries without any runtime libraries. See discussion
about this on https://reviews.llvm.org/D15225.
llvm-svn: 338444
Summary:
The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi) for 2 reasons:
1. OpenEmbedded sysroots are of the form <sysroot>/usr/lib/<triple>/x.y.z. This form is handled in clang but only for Freescale vendor.
2. 64-bit OpenEmbedded sysroots may not have a /usr/lib dir. So they cannot find /usr/lib64 as it is referenced as /usr/lib/../lib64 in clang.
This is a follow-up to the llvm patch: D48861
Reviewers: dlj, rengolin, fedor.sergeev, javed.absar, hfinkel, rsmith
Reviewed By: rsmith
Subscribers: rsmith, kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D48862
llvm-svn: 338294
gcc 7.2 under Amazon Linux AMI sets its paths to x86_64-amazon-linux. Adding
this triple to the list of search, plus a test case to cover this.
The patch fixes the following bug reported in bugzilla:
https://bugs.llvm.org/show_bug.cgi?id=35992
Reviewers: echristo
Differential Revision: https://reviews.llvm.org/D46230
llvm-svn: 337811
The runtime libraries of sanitizers are built in compiler-rt, and Clang
can be built without compiler-rt, or compiler-rt can be configured to
only build certain sanitizers. The driver should provide reasonable
diagnostics and not a link-time error when a runtime library is missing.
This patch changes the driver for OS X to only support sanitizers of
which we can find the runtime libraries. The discussion for this patch
explains the rationale
Differential Revision: https://reviews.llvm.org/D15225
llvm-svn: 337635
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
Summary:
Use oclc_daz_opt_on.amdgcn.bc bitcode when option fcuda-flush-denormal-to-zero is enabled, otherwise use oclc_daz_opt_off.amdgcn.bc bitcode. Added lit tests to verify that the correct bitcode is linked when -fcuda-flush-denormal-to-zero option is enabled or disabled.
Reviewers: yaxunl, scchan, b-sumner
Reviewed By: yaxunl, scchan, b-sumner
Subscribers: cfe-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D48493
llvm-svn: 335765
This patch adds HIP toolchain to support HIP language mode. It includes:
Create specific compiler jobs for HIP.
Choose specific libraries for HIP.
With contribution from Greg Rodgers.
Differential Revision: https://reviews.llvm.org/D45212
llvm-svn: 333484
Currently LLVM CFI tries to use an implicit blacklist file, currently
in /usr/lib64/clang/<version>/share. If the file is not there, LLVM
happily continues, which causes CFI to add checks to files/functions
that are known to fail, generating binaries that fail. This CL causes
LLVM to die (I hope) if it can't find these implicit blacklist files.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D46403
llvm-svn: 331674
This avoids warnings about unused linker parameters, just like
other flags are ignored if they're from config files.
Differential Revision: https://reviews.llvm.org/D46286
llvm-svn: 331504
Implementation of `InputArgList` assumes its field `ArgStrings` contains
strings for each argument exactly in the same order. This condition was
broken when arguments from config file and from invocation were merged.
This change fixes https://bugs.llvm.org/show_bug.cgi?id=37196 (Clang
config files can crash argument handling).
llvm-svn: 330926
Previously it would only accept a string as a GCC version if it had
either two components and no suffix, or three components with an
optional suffix.
Debian and ubuntu provided mingw compilers have lib/gcc/target entries
like "5.3-posix" and "5.3-win32". This doesn't try to make any specific
preference between them (other than lexical sorting of the suffix).
Differential Revision: https://reviews.llvm.org/D45505
llvm-svn: 330696
Summary:
Android sysroots contain libraries for each OS version, as well as a
handful of unversioned libraries in the typical multiarch directory.
Reviewers: srhines, eugenis, george.burgess.iv
Reviewed By: eugenis
Subscribers: javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D45290
llvm-svn: 330213
Summary:
1. Find GCC's LDPATH from the actual GCC config file.
2. Avoid picking libraries from a similar named tuple if the exact
tuple is installed.
Reviewers: mgorny, chandlerc, thakis, rnk
Reviewed By: mgorny, rnk
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D45233
llvm-svn: 329512
Summary:
Most Android headers live in a single directory, but a small handful
live in multiarch directories.
Reviewers: srhines
Reviewed By: srhines
Subscribers: javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D44995
llvm-svn: 329234
Summary: Porting HWASan to Linux x86-64, the third of the three patches, clang part.
Reviewers: eugenis
Subscribers: cryptoad, cfe-commits
Differential Revision: https://reviews.llvm.org/D44745
llvm-svn: 328361
Summary: This patch adds an additional flag to the OpenMP device offloading toolchain to link in the runtime library bitcode.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, grokos, hfinkel
Reviewed By: ABataev, grokos
Subscribers: jholewinski, guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D43197
llvm-svn: 327460
Sam Elliott