summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/Driver.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Turn ArchName/BoundArch in Driver from raw pointer to StringRef (NFC)Mehdi Amini2016-10-071-9/+9
| | | | llvm-svn: 283605
* Revert r283572 - [Driver] Make -print-libgcc-file-name print compiler-rt lib ↵Michal Gorny2016-10-071-9/+1
| | | | | | | | | | when used 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
* [Driver] Make -print-libgcc-file-name print compiler-rt lib when usedMichal Gorny2016-10-071-1/+9
| | | | | | | | | | | | | | | | | | | | 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
* [Driver] Add driver support for FuchsiaPetr Hosek2016-10-061-0/+3
| | | | | | | | | | | 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
* Taking StringRef in Driver.h APIs instead of raw pointers (NFC)Mehdi Amini2016-10-061-34/+32
| | | | llvm-svn: 283417
* clang-cl: Make /Fo apply also when using -fltoHans Wennborg2016-10-041-1/+1
| | | | llvm-svn: 283258
* [CUDA][OpenMP] Add a generic offload action builderSamuel Antao2016-09-301-161/+557
| | | | | | | | | | | | | | | | | | | | | | 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
* Unrevert r280035 now that the clang-cl bug it exposed has been fixed byRichard Smith2016-08-301-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) ↵Richard Smith2016-08-301-2/+6
| | | | | | input types. llvm-svn: 280133
* Revert r280035 (and followups r280057, r280085), it caused PR30195Nico Weber2016-08-301-11/+3
| | | | llvm-svn: 280091
* C++ Modules TS: driver support for building modules.Richard Smith2016-08-301-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CUDA] Collapsed offload actions should not be top-level jobs.Artem Belevich2016-08-221-1/+1
| | | | | | | | | | | | 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
* [Driver] Set the default driver mode based on the executable.Zachary Turner2016-08-121-18/+26
| | | | | | | | | | | | | | | | | | 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
* [CUDA] Do not allow using NVPTX target for host compilation.Artem Belevich2016-08-021-6/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D23042 llvm-svn: 277537
* Retry: [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-271-0/+13
| | | | | | | | | | | | | | | | 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
* Revert "[Driver] Compute effective target triples once per job (NFCI)"Vedant Kumar2016-07-271-15/+1
| | | | | | | 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
* [Driver] Switch some getenv calls to llvm::sys::Process::GetEnvDavid Majnemer2016-07-241-2/+3
| | | | | | No functional change is intended. llvm-svn: 276573
* [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-181-1/+15
| | | | | | | | | | 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
* [Driver] Make Driver::DefaultTargetTriple private (NFCI)Vedant Kumar2016-07-181-3/+3
| | | | | | | | | | | | 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
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* [CUDA][OpenMP] Create generic offload actionSamuel Antao2016-07-151-111/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CUDA] Add utility functions for dealing with CUDA versions / architectures.Justin Lebar2016-07-061-13/+16
| | | | | | | | | | | | | | | | | | 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
* Use ArgList::hasFlag to check if -miamcu/-mno-iamcu is passed. NFC.Andrey Turetskiy2016-06-291-21/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D21641 llvm-svn: 274119
* [X86] Add -mno-iamcu option.Andrey Turetskiy2016-06-201-18/+21
| | | | | | | | | | 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
* Compilation for Intel MCU (Part 2/3)Andrey Turetskiy2016-06-161-0/+1
| | | | | | | | | | | | 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
* [CUDA][OpenMP] Create generic offload toolchainsSamuel Antao2016-06-131-14/+29
| | | | | | | | | | | | | | | | | | | 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
* Revert "Strip Android version when looking up toolchain paths."Chandler Carruth2016-06-111-9/+1
| | | | | | | This reverts commit r272413. The tests here have been failing on several different build bots for over 10 hours. llvm-svn: 272454
* Strip Android version when looking up toolchain paths.Josh Gao2016-06-101-1/+9
| | | | | | | | | | | | | | | | 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
* Apply clang-tidy's misc-move-constructor-init throughout Clang.Benjamin Kramer2016-05-271-3/+4
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270996
* [Driver] Fix the case when use -fembed-bitcode and -flto= togetherSteven Wu2016-05-181-3/+3
| | | | | | | | | | | | | | | | | 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
* Embed bitcode in object file (clang cc1 part)Steven Wu2016-05-111-6/+15
| | | | | | | | | | | | | | | | | | | 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
* Update clang support on recent HaikuReid Kleckner2016-05-111-0/+3
| | | | | | | | | | | | | | | | | | [ 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
* driver: Add a `--rsp-quoting` flag to pick response file quoting.Nico Weber2016-04-251-1/+2
| | | | | | | | | | | | | | | | | | | | 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
* clang-cl: Don't assert on using /Yc with non-source files, PR27450Nico Weber2016-04-211-19/+19
| | | | | | Move phase handling after input type validation. llvm-svn: 267040
* Compilation for Intel MCU (Part 1/3)Andrey Turetskiy2016-04-211-8/+33
| | | | | | | | | | | Add -miamcu option which: * Sets IAMCU triple * Sets IAMCU ABI * Enforces static compilation Differential Revision: http://reviews.llvm.org/D18398 llvm-svn: 266972
* Revert r266747 (Compilation for Intel MCU (Part 1/3)) since it breaks a few ↵Andrey Turetskiy2016-04-191-33/+8
| | | | | | buildbots. llvm-svn: 266753
* Compilation for Intel MCU (Part 1/3)Andrey Turetskiy2016-04-191-8/+33
| | | | | | | | | | | Add -miamcu option which: * Sets IAMCU triple * Sets IAMCU ABI * Enforces static compilation Differential Revision: http://reviews.llvm.org/D18398 llvm-svn: 266747
* [CUDA] Add --cuda-compile-host-device, which overrides --cuda-host-only and ↵Justin Lebar2016-04-191-11/+17
| | | | | | | | | | | | | | | | --cuda-device-only. 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
* clang-cl: Don't check for existence of linker inputs when /link is usedHans Wennborg2016-04-151-7/+16
| | | | | | | | | There might be flags passed to the linker (e.g. /libpath), causing it to search in paths the Clang driver doesn't know about. PR27234 llvm-svn: 266402
* [DarwinDriver] Increase the number of valid digits for ld64 version string.Bruno Cardoso Lopes2016-03-311-0/+28
| | | | | | | | | | Previously only 3 digits were valid. Increase it to 5. Differential Revision: http://reviews.llvm.org/D18304 rdar://problem/24843016 llvm-svn: 264987
* [CUDA] Don't initialize the CUDA toolchain if we don't have any CUDA inputs.Justin Lebar2016-03-301-4/+13
| | | | | | | | | | | | | | | | | | | | 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
* [lanai] Add Lanai backend to clang driver.Jacques Pienaar2016-03-281-0/+3
| | | | | | | | | | Changes to clang to add Lanai backend. Adds a new target, ABI and toolchain. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17002 llvm-svn: 264655
* clang-cl: Enable PCH flags by default.Nico Weber2016-03-041-8/+0
| | | | | | | | | | | | | 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
* clang-cl pch test: Instead of copying the input, use /Fp to not write into ↵Nico Weber2016-03-021-1/+1
| | | | | | | | | the test directory. Also fix a bug with /Fp and absolute paths uncovered by this. Follow-up to r262487. llvm-svn: 262541
* clang-cl: Implement initial limited support for precompiled headers.Nico Weber2016-03-011-1/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce -fembed-bitcode driver optionSteven Wu2016-03-011-10/+36
| | | | | | | | | | | | | | | | | | | | | 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
* Rename Action::begin() to Action::input_begin().Nico Weber2016-02-231-15/+16
| | | | | | | | 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
* Remove unused ToolChain arg from Driver::ConstructPhaseAction and BuildAction.Justin Lebar2016-02-111-13/+9
| | | | | | | | | | | | | | | | 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
* [MSVC Compat] Only warn for unknown clang-cl argumentsEhsan Akhgari2016-01-251-3/+8
| | | | | | | | | | | | | | | | | 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
* Respect bound archs, even when they don't alter the toolchain.Justin Lebar2016-01-161-2/+9
| | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud