| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
- remove path to dts-1.x (corresponds to gcc 4.7)
- add path to dts-6 (corresponds to 6.x)
Patch By: Maria Gottschalk
Differential Revision: https://reviews.llvm.org/D29855
llvm-svn: 296485
|
|
|
|
|
|
|
|
|
|
|
| |
The runtime support is provided directly by the Fuchsia system C
library.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D30238
llvm-svn: 296082
|
|
|
|
| |
llvm-svn: 295536
|
|
|
|
|
|
|
|
|
|
| |
freescale triple.
On multiarch systems, this previously caused us to stat every file in
/usr/lib/<triple> (typically several thousand files). This change halves
the runtime of a clang invocation on an empty file on my system.
llvm-svn: 295140
|
|
|
|
|
|
| |
that are only checked for some targets.
llvm-svn: 295139
|
|
|
|
|
|
|
|
|
| |
This is a missed part of https://reviews.llvm.org/D28609.
Enable LSan for x86 Linux in clang driver.
Differential Revision: https://reviews.llvm.org/D29077
llvm-svn: 293609
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r279546 I disabled all frame pointer elimination at the front-end on
ARM-Darwin (and warned about it) because before that the backend had been
silently ignoring these options. It turns out we didn't ignore
-momit-leaf-frame-pointer though, just the more general -fomit-frame-pointer.
So this re-enables passing that down to CodeGen so that everything really does
continue working as before (with better diagnostics).
llvm-svn: 293311
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch teaches the Clang driver how to handle the N64 static
relocation model properly. It enforces the correct target feature
(+noabicalls) when -fno-pic is used. This is required as non-pic
N64 code as the abi extension to call PIC code (CPIC) is unsupported.
Make PIC the default for mips64 and mips64el, this affects both N32
& N64 ABIs, to better match GCC.
As part of this effort, clean up the assembler invocation command
builder, so the correct flags are used.
This and r293279 in LLVM resolves PR/23485.
Thanks to Brooks Davis for reporting the issue!
Reviewers: slthakur, seanbruno
Differential Revision: https://reviews.llvm.org/D29031
llvm-svn: 293285
|
|
|
|
|
|
| |
Also accept -G= (and -msmall-data-threshold=) as an alias for -G on MIPS as well as Hexagon.
llvm-svn: 293254
|
|
|
|
|
|
|
|
|
| |
Hexagon Linux dynamic loader does not use (in fact does not support)
.gnu-hash
Differential Revision: https://reviews.llvm.org/D28865
llvm-svn: 292496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
openSuse has AArch64 support, with images running on the Raspberry Pi 3.
The libraries and headers live under the aarch64-suse-linux subdirectory,
which is currently not in the AArch64 triples list. Address this by adding
the corresponding string to AArch64Triples.
Reviewers: chandlerc, bruno, bkramer, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D28238
llvm-svn: 291598
|
|
|
|
| |
llvm-svn: 291436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For the most part this is straightforward: Just add a CudaInstallation
object to the MSVC and MinGW toolchains.
CudaToolChain has to override computeMSVCVersion so that
Clang::constructJob passes the right version flag to cc1. We have to
modify IsWindowsMSVC and friends in Clang::constructJob to be true when
compiling CUDA device code on Windows for the same reason.
Depends on: D28319
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28320
llvm-svn: 291131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously it was taking the true target triple, which is not really
what it needs: The location of the CUDA installation depends on the host
OS.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28319
llvm-svn: 291130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
|
|
|
|
|
|
|
| |
This reverts commit r290569. It caused unforeseen codegen changes for
switch jump tables described in PR31488.
llvm-svn: 290672
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows uses PE/COFF which is inherently position independent. The use
of the PIC model is unnecessary. In fact, we would generate invalid
code using the ELF PIC model when PIC was enabled previously. Now that
we no longer accept -fPIC and -fpoc, this switches the internal
representation to the static model to permit us to make PIC modules
invalid when targeting Windows. This should not change the code
generation, only the internal state management.
llvm-svn: 290569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the PowerPC64 code generation already creates PIC access. This
changes to a full PIC default, similar to what GCC is doing.
Overall, a monolithic clang binary shrinks by 600KB (about 1%). This can
be a slight regression for TLS access and will use the TOC more
aggressively instead of synthesizing immediates. It is expected to be
performance neutral.
Differential Revision: https://reviews.llvm.org/D26564
llvm-svn: 289744
|
|
|
|
|
|
|
|
|
| |
This change allows setting the default linker used by the Clang
driver when configuring the build.
Differential Revision: https://reviews.llvm.org/D25263
llvm-svn: 289668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc directory (due to matching
installation triple), and -m32 not respecting gcc-config at all (due to
mismatched installation triple).
In order to fix the former issue, split the multilib scan out of
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple() (the code
is otherwise unchanged), and call it for each installation found via
gcc-config.
In order to fix the latter issue, split the gcc-config processing out of
Generic_GCC::GCCInstallationDetector::init() and repeat it for all
triples, including extra and biarch triples. The only change
in the gcc-config code itself is adding the call to multilib scan.
Convert the gentoo_linux_gcc_multi_version_tree test input to multilib
x86_64+32+x32 install, and add appropriate tests to linux-header-search
and linux-ld.
Differential Revision: https://reviews.llvm.org/D26887
llvm-svn: 289436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is an improvement on rL288448 where address sanitization was listed
as supported for the CudaToolChain. Since the intent is for the
CudaToolChain not to reject any flags supported by the host compiler,
this patch switches to forwarding the CudaToolChain sanitizer support to
the host toolchain rather than explicitly whitelisting address
sanitization.
Thanks to hfinkel for this suggestion.
Reviewers: jlebar
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D27351
llvm-svn: 288512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that was introduced in rL287285. The bug made it
illegal to pass -fsanitize=address during CUDA compilation because the
CudaToolChain class was switched from deriving from the Linux toolchain
class to deriving directly from the ToolChain toolchain class. When
CudaToolChain derived from Linux, it used Linux's getSupportedSanitizers
method, and that method allowed ASAN, but when it switched to deriving
directly from ToolChain, it inherited a getSupportedSanitizers method
that didn't allow for ASAN.
This patch fixes that bug by creating a getSupportedSanitizers method
for CudaToolChain that supports ASAN.
This patch also fixes the test that checks that -fsanitize=address is
passed correctly for CUDA builds. That test didn't used to notice if an
error message was emitted, and that's why it didn't catch this bug when
it was first introduced. With the fix from this patch, that test will
now catch any similar bug in the future.
llvm-svn: 288448
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the Distro enum along with helper functions into a full-fledged
Distro class, inspired by llvm::Triple, and make it a public API.
The new class wraps the enum with necessary comparison operators, adding
the convenience Is*() methods and a constructor performing
the detection. The public API is needed to run the unit tests (D25869).
Differential Revision: https://reviews.llvm.org/D25949
llvm-svn: 288060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Compiling CUDA device code requires us to know the host toolchain,
because CUDA device-side compiles pull in e.g. host headers.
When we only supported Linux compilation, this worked because
CudaToolChain, which is responsible for device-side CUDA compilation,
inherited from the Linux toolchain. But in order to support MacOS,
CudaToolChain needs to take a HostToolChain pointer.
Because a CUDA toolchain now requires a host TC, we no longer will
create a CUDA toolchain from Driver::getToolChain -- you have to go
through CreateOffloadingDeviceToolChains. I am *pretty* sure this is
correct, and that previously any attempt to create a CUDA toolchain
through getToolChain() would eventually have resulted in us throwing
"error: unsupported use of NVPTX for host compilation".
In any case hacking getToolChain to create a CUDA+host toolchain would
be wrong, because a Driver can be reused for multiple compilations,
potentially with different host TCs, and getToolChain will cache the
result, causing us to potentially use a stale host TC.
So that's the main change in this patch.
In addition, we have to pull CudaInstallationDetector out of Generic_GCC
and into a top-level class. It's now used by the Generic_GCC and MachO
toolchains.
Reviewers: tra
Subscribers: rryan, hfinkel, sfantao
Differential Revision: https://reviews.llvm.org/D26774
llvm-svn: 287285
|
|
|
|
| |
llvm-svn: 287112
|
|
|
|
| |
llvm-svn: 286716
|
|
|
|
| |
llvm-svn: 285500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain.
With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21848
llvm-svn: 285320
|
|
|
|
| |
llvm-svn: 285140
|
|
|
|
|
|
|
|
|
| |
Disable the OpenSUSE rules for OpenSUSE versions older than 11 as they
are incompatible with the old binutils on that distribution.
Differential Revision: https://reviews.llvm.org/D24954
llvm-svn: 285076
|
|
|
|
|
|
|
|
|
|
|
| |
Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-config configuration
form [[sysroot]]/etc/env.d/gcc, if no custom toolchain location is
provided.
Differential Revision: https://reviews.llvm.org/D25661
llvm-svn: 285074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the DetectDistro() function to take a single vfs::FileSystem
reference only, instead of Driver and llvm::Triple::ArchType.
The ArchType parameter was not used anyway, and Driver was only used to
obtain the VFS.
Aside to making the API simpler and more transparent, it makes it
easier to add unit tests for the function in the future -- since
the tests would need only to provide an appropriate VFS.
Differential Revision: https://reviews.llvm.org/D25819
llvm-svn: 284774
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the string matching for /etc/debian_version with split
integer/string matching algorithm. When the file contains 'major.minor'
version number, parse the major version as integer and use a switch
clause to match it. Otherwise, attempt 'codename/sid' matching using
a StringSwitch.
Differential Revision: https://reviews.llvm.org/D25696
llvm-svn: 284770
|
|
|
|
| |
llvm-svn: 284617
|
|
|
|
|
|
|
|
|
|
|
| |
System utilities such as atos only support DWARF 4 on OS X 10.11+ and
iOS 9+. We thus want to enable DWARF 4 only if the deployment target
has a recent enough operating system version and use DWARF 2 for older
systems.
<rdar://problem/28766743>
llvm-svn: 284416
|
|
|
|
|
|
|
|
|
|
| |
Use the VFS provided by D.getVFS() for all distribution checks,
including those performing read of the release file. Requested
by @bruno on D24954.
Differential Revision: https://reviews.llvm.org/D25641
llvm-svn: 284403
|
|
|
|
| |
llvm-svn: 284392
|
|
|
|
| |
llvm-svn: 284389
|
|
|
|
|
|
|
| |
This problem was exposed by r284129, causing clang-hexagon-elf to fail
clang tests.
llvm-svn: 284383
|
|
|
|
|
|
|
|
| |
Patch by Michael LeMay
Differential revision: http://reviews.llvm.org/D19854
llvm-svn: 284278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were reverted in r283753 and r283747.
The first patch added a header to the root 'Headers' install directory,
instead of into 'Headers/cuda_wrappers'. This was fixed in the second
patch, but by then the damage was done: The bad header stayed in the
'Headers' directory, continuing to break the build.
We reverted both patches in an attempt to fix things, but that still
didn't get rid of the header, so the Windows boostrap build remained
broken.
It's probably worth fixing up our cmake logic to remove things from the
install dirs, but in the meantime, re-land these patches, since we
believe they no longer have this bug.
llvm-svn: 283907
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Breaks bootstrap builds on (at least) Windows:
In file included from D:\buildslave\clang-x64-ninja-win7\llvm\lib\Support\Allocator.cpp:14:
In file included from D:\buildslave\clang-x64-ninja-win7\llvm\include\llvm/Support/Allocator.h:24:
In file included from D:\buildslave\clang-x64-ninja-win7\llvm\include\llvm/ADT/SmallVector.h:20:
In file included from D:\buildslave\clang-x64-ninja-win7\llvm\include\llvm/Support/MathExtras.h:19:
D:\buildslave\clang-x64-ninja-win7\stage1.install\bin\..\lib\clang\4.0.0\include\algorithm(63,8) :
error: unknown type name '__device__'
inline __device__ const __T &
llvm-svn: 283747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We do this by wrapping <complex> and <algorithm>.
Tests are in the test-suite.
Reviewers: tra
Subscribers: jhen, beanz, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24979
llvm-svn: 283680
|
|
|
|
| |
llvm-svn: 283611
|
|
|
|
| |
llvm-svn: 283605
|
|
|
|
|
|
|
|
|
|
|
| |
Provide toolchain and tool support for Fuchsia operating system.
Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi
and libunwind as the C++ standard library. lld is used as a default
linker.
Differential Revision: https://reviews.llvm.org/D25117
llvm-svn: 283420
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24946
llvm-svn: 282610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately we can't enable it for all N64 because it is not yet possible to
distinguish N32 from N64 from the triple on other environments.
N64 has been confirmed to produce identical (within reason) objects to GAS
during stage 2 of compiler recursion on N64-abi Fedora. Unfortunately,
Fedora's triples do not distinguish N32 from N64 so I can't enable it by
default there. I'm currently repeating this testing for Debian mips64el but
it's very unlikely to produce a different result.
Patch by: Daniel Sanders
Reviewers: sdardis
Differential Review: https://reviews.llvm.org/D22679
llvm-svn: 281610
|
|
|
|
|
|
| |
Doesn't work, but needs to be enabled in order to get there.
llvm-svn: 281071
|