Revert the -print-libgcc-file-name change as the new test fails
on Darwin. It needs to be updated to run the libgcc part only on systems
supporting that rtlib.
llvm-svn: 283586
Make the -print-libgcc-file-name option print an appropriate compiler
runtime library, that is libgcc.a if gcc runtime is used
and an appropriate compiler-rt library if that runtime is used.
The main use for this is to allow linking executables built with
-nodefaultlibs (e.g. to avoid linking to the standard C++ library) to
the compiler runtime library, e.g. using:
clang++ ... -nodefaultlibs $(clang++ ... -print-libgcc-file-name)
in which case currently a program built like this linked to the gcc
runtime unconditionally. The patch fixes it to use compiler-rt libraries
instead when compiler-rt is the active runtime.
Differential Revision: https://reviews.llvm.org/D25338
llvm-svn: 283572
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
Summary:
This patch proposes a new class to generate and record action dependences related with offloading. The builder provides three main functionalities:
- Add device dependences to host actions.
- Add host dependence to device actions.
- Register device top-level actions.
The constructor of the builder detect the programming models that should be supported, and generates a specialized builder for each. If a new programming model is to be added in the future, only a new specialized builder has to be implemented.
When the specialized builder is generated, it produces programming-model-specific diagnostics.
A CUDA specialized builder is proposed in the patch that mostly consists of the partition of the current `buildCudaAction` by the three different functionalities.
Reviewers: tra, echristo, ABataev, jlebar, hfinkel
Subscribers: Hahnfeld, whchung, guansong, jlebar, mehdi_amini, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18172
llvm-svn: 282865
r280133. Original commit message:
C++ Modules TS: driver support for building modules.
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
llvm-svn: 280134
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
llvm-svn: 280035
If they are, we end up with the last intermediary output preserved
in the current directory after compilation.
Added a test case to verify that we're using appropriate filenames
for outputs of different phases.
Differential Revision: https://reviews.llvm.org/D23526
llvm-svn: 279455
Currently, if --driver-mode is not passed at all, it will default
to GCC style driver. This is never an issue for clang because
it manually constructs a --driver-mode option and passes it.
However, we should still try to do as good as we can even if no
--driver-mode is passed. LibTooling, for example, does not pass
a --driver-mode option and while it could, it seems like we should
still fallback to the best possible default we can.
This is one of two steps necessary to get clang-tidy working on Windows.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D23454
llvm-svn: 278535
Compute an effective triple once per job. Cache the triple in the
prevailing ToolChain for the duration of the job.
Clients which need effective triples now look them up in the ToolChain.
This eliminates wasteful re-computation of effective triples (e.g in
getARMFloatABI()).
While we're at it, delete MachO::ComputeEffectiveClangTriple. It was a
no-op override.
Differential Revision: https://reviews.llvm.org/D22596
llvm-svn: 276937
This reverts commit r275895 in order to address some post-commit review
feedback from Eric Christopher (see: the list thread for r275895).
llvm-svn: 276936
Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).
Differential Revision: https://reviews.llvm.org/D22290
llvm-svn: 275895
No in-tree targets access this `DefaultTargetTriple` directly, and usage
of default triples is generally discouraged. Make the field private.
This is part of en effort to make the clang driver use effective triples
more pervasively.
Differential Revision: https://reviews.llvm.org/D22289
llvm-svn: 275894
Summary:
This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.
This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.
This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)
```
0: input, "cudatests.cu", cuda, (host-cuda)
1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
2: compiler, {1}, ir, (host-cuda)
3: input, "cudatests.cu", cuda, (device-cuda, sm_35)
4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)
5: compiler, {4}, ir, (device-cuda, sm_35)
6: backend, {5}, assembler, (device-cuda, sm_35)
7: assembler, {6}, object, (device-cuda, sm_35)
8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object
9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler
10: input, "cudatests.cu", cuda, (device-cuda, sm_37)
11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)
12: compiler, {11}, ir, (device-cuda, sm_37)
13: backend, {12}, assembler, (device-cuda, sm_37)
14: assembler, {13}, object, (device-cuda, sm_37)
15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object
16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler
17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)
18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir
19: backend, {18}, assembler
20: assembler, {19}, object
21: input, "cuda", object
22: input, "cudart", object
23: linker, {20, 21, 22}, image
```
The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.
Reviewers: echristo, hfinkel, jlebar, ABataev, tra
Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18171
llvm-svn: 275645
Summary:
Currently our handling of CUDA architectures is scattered all around
clang. This patch centralizes it.
A key advantage of this centralization is that you can now write a C++
switch on e.g. CudaArch and get a compile error if you don't handle one
of the enum values.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21867
llvm-svn: 274681
Add -mno-iamcu option to:
1) Countervail -miamcu option easily
2) Be compatible with GCC which supports this option
Differential Revision: http://reviews.llvm.org/D21469
llvm-svn: 273147
This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Recognize and use IAMCU GCC toolchain
* Set up include paths
* Forbid C++
Differential Revision: http://reviews.llvm.org/D19274
llvm-svn: 272883
Summary:
This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading.
It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading.
This patch does not add tests - its goal is to keep the existing functionality.
This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet.
Reviewers: ABataev, jlebar, echristo, hfinkel, tra
Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: http://reviews.llvm.org/D18170
llvm-svn: 272571
Summary:
Android target triples can include a version number in the abi field
(e.g. 'aarch64-linux-android21'), used for checking for availability.
However, the driver was searching for toolchain binaries using the
passed in triple as a prefix.
Reviewers: srhines, danalbert, t.p.northover
Subscribers: t.p.northover, aemerson, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D21163
llvm-svn: 272413
Summary:
-fembed-bitcode was only checking for old style LTO flag (-flto) but not
considering the new -flto= style option. That makes clang output bitcode
embedded in bitcode object when using -flto= and -fembed-bitcode= together.
Now clang should output normal bitcode file when using LTO and ignores
-fembed-bitcode option.
Reviewers: joker.eph
Subscribers: joker.eph, cfe-commits
Differential Revision: http://reviews.llvm.org/D20374
llvm-svn: 269961
Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file. Using -fembed-bitcode-marker will only introduce a
marker in both sections.
Depends on D17390
Reviewers: rsmith
Subscribers: yaron.keren, vsk, cfe-commits
Differential Revision: http://reviews.llvm.org/D17392
llvm-svn: 269202
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ]
clang support on Haiku is lagging a bit, and missing on x86_64.
This patch updates support for x86 and add support for x86_64. It should
apply directly to trunk and it's harmless in the sense that it only
affects Haiku.
Reviewers: rnk, rsmith
Patch by Jérôme Duval
Differential Revision: http://reviews.llvm.org/D16797
llvm-svn: 269201
Currently, clang-cl always uses Windows style for unquoting, and clang always
uses POSIX style for unquoting.
With this flag, it's possible to change these defaults.
In general, response file quoting should match the shell the response file is
used in. On Windows, it's possible to run clang-cl in a bash shell, or clang in
cmd.exe, so a flag for overriding the default behavior is natural there.
On non-Windows, Windows quoting probably never makes sense (except maybe in
Wine), but having clang-cl behave differently based on the host OS seems
strange too. So require that people who want to use posix-style response
files with clang-cl on non-Windows pass --rsp-quoting=posix.
http://reviews.llvm.org/D19425
llvm-svn: 267474
Summary:
This completes the flag's tristate, letting you override it at will on
the command line.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D19248
llvm-svn: 266707
Summary:
This prevents errors when you invoke clang with a flag that the NVPTX
toolchain doesn't support. For example, on x86-64,
clang -mthread-model single -x c++ /dev/null -o /dev/null
should output just one error about "invalid thread model 'single' in
'-mthread-model single' for this target"; x86-64 doesn't support
-mthread-model, but we shouldn't also instantiate a NVPTX target!
Reviewers: echristo
Subscribers: tra, sunfish, cfe-commits
Differential Revision: http://reviews.llvm.org/D18629
llvm-svn: 264965
Now that pragma comment and pragma detect_mismatch are implemented, this might
just work.
Some pragmas aren't serialized yet (from the top of my head: code_seg, bss_seg,
data_seg, const_seg, init_seg, section, vtordisp), but these are as far as I
know usually pushed and popped within the header and usually don't leak out.
If it turns out the current PCH support isn't good enough yet, we can turn it
off again.
llvm-svn: 262749
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
llvm-svn: 262420
Summary:
This is the clang driver part of the change to embedded bitcode. This
includes:
1. -fembed-bitcode option which breaks down the compilation into two
stages. The first stage emits optimized bitcode and the second stage
compiles bitcode into object file.
2. -fembed-bitcode-marker option which doesn't really break down to
two stages to speedup the compilation flow.
3. pass the correct linker flag to darwin linker if tool chains supports
embedded bitcode.
Reviewers: rsmith, thakis
Subscribers: thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D17390
llvm-svn: 262282
Also introduce inputs() that reutnrs an llvm::iterator_range.
Iterating over A->inputs() is much less mysterious than
iterating over *A. No intended behavior change.
llvm-svn: 261674
Summary:
Actions don't depend on the toolchain; they get bound to a particular
toolchain via BindArch.
No functional changes.
Reviewers: echristo
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17100
llvm-svn: 260478
Summary:
MSVC's driver accepts all unknown arguments but warns about them. clang
by default rejects all unknown arguments. This causes issues
specifically with build systems such as autoconf which liberally pass
things such as $LDFLAGS to the compiler and expect everything to work.
This patch teaches clang-cl to ignore unknown driver arguments.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16511
llvm-svn: 258720
Summary:
It's possible to BindArch without changing the toolchain at all. For
example, armv7 and armv7s have exactly the same toolchain triple.
Therefore the code in the Driver that checks that we're not creating a
job for the same Action twice needs to consider (Action, Toolchain,
BoundArch) tuples.
Reviewers: tra
Subscribers: aemerson, echristo, beanz, cfe-commits
Differential Revision: http://reviews.llvm.org/D16250
llvm-svn: 257983
Summary:
Previously we compiled CUDA device code to PTX assembly and embedded
that asm as text in our host binary. Now we compile to PTX assembly and
then invoke ptxas to assemble the PTX into a cubin file. We gather the
ptx and cubin files for each of our --cuda-gpu-archs and combine them
using fatbinary, and then embed that into the host binary.
Adds two new command-line flags, -Xcuda_ptxas and -Xcuda_fatbinary,
which pass args down to the external tools.
Reviewers: tra, echristo
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D16082
llvm-svn: 257809
Michal Gorny