summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/Driver.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [CUDA] Invoke ptxas and fatbinary during compilation.Justin Lebar2016-01-141-16/+36
| | | | | | | | | | | | | | | | | | | | 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
* Don't build jobs for the same Action + ToolChain twice.Justin Lebar2016-01-141-14/+36
| | | | | | | | | | | | | | | Summary: Right now if the Action graph is a DAG and we encounter an action twice, we will run it twice. This patch is difficult to test as-is, but I have testcases for this as used within CUDA compilation. Reviewers: Subscribers: llvm-svn: 257808
* [CUDA] Reject values for --cuda-gpu-arch that are not of the form /sm_\d+/.Justin Lebar2016-01-111-2/+6
| | | | | | | | | | Reviewers: tra Subscribers: cfe-commits, jhen, echristo Differential Revision: http://reviews.llvm.org/D16079 llvm-svn: 257413
* Add an Action* member to InputInfo.Justin Lebar2016-01-111-6/+6
| | | | | | | | | | | | | | Summary: The CUDA toolchain needs to know which Actions created which InputInfos, because it needs to attach GPU archs to the various InputInfos. Reviewers: echristo Subscribers: jfb, dschuff, jhen, tra, cfe-commits Differential Revision: http://reviews.llvm.org/D16078 llvm-svn: 257411
* Make Driver::BuildJobsForAction return an InputInfo, instead of using an ↵Justin Lebar2016-01-111-35/+26
| | | | | | | | | | | | | | outparam. Summary: Explicit is better than implicit. Reviewers: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16013 llvm-svn: 257408
* Move ownership of Action objects into Compilation.Justin Lebar2016-01-111-62/+47
| | | | | | | | | | | | | | | | Summary: This makes constructing Action graphs which are DAGs much simpler. It also just simplifies in general the ownership semantics of Actions. Depends on D15910. Reviewers: echristo Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D15911 llvm-svn: 257407
* Update code in buildCudaActions and BuildActions to latest idiom.Justin Lebar2016-01-081-18/+14
| | | | | | | | | | | | | | | Summary: Use llvm::any_of, llvm::find, etc. No functional changes. Reviewers: tra Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15936 llvm-svn: 257190
* [Clang/Support/Windows/Unix] Command lines created by clang may exceed the ↵Oleg Ranevskyy2016-01-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | command length limit set by the OS Summary: LLVM part of the patch is D15831. When clang runs an external tool such as a linker it may create a command line that exceeds the length limit. Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS limitation. There are two problems in this function that may cause exceeding of the limit: 1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program path to the command line when it runs the program. 2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails. Reviewers: rafael, asl Subscribers: asl, llvm-commits Differential Revision: http://reviews.llvm.org/D15832 llvm-svn: 256865
* Fix rewrite of reserved library name in case of -nodefaultlibsNirav Dave2015-11-241-1/+2
| | | | | | | | | | | | The Driver only checked if nostdlib was set when deciding to add reserved_lib_stdcxx, but as nostdlib is always exactly nodefaultlibs and nostartfiles we should be checking one (clearly nodefaultlibs in the case) as well. This appears to be the only such instance of this in the codebase. Differential Revision: http://reviews.llvm.org/D14935 llvm-svn: 253990
* [CUDA] use -aux-triple to pass target triple of opposite side of compilationArtem Belevich2015-11-171-34/+38
| | | | | | | | | | | | | | | | Clang needs to know target triple for both sides of compilation so that preprocessor macros and target builtins from both sides are available. This change augments Compilation class to carry information about toolchains used during different CUDA compilation passes and refactors BuildActions to use it when it constructs CUDA jobs. Removed DeviceTriple from CudaHostAction/CudaDeviceAction as it's no longer needed. Differential Revision: http://reviews.llvm.org/D13144 llvm-svn: 253385
* Re-recommit: Add support for the new mips-mti-linux toolchain.Vasileios Kalintiris2015-11-121-0/+8
| | | | | | | | Last time, this caused two Windows buildbots and a single ARM buildbot to fail. I XFAIL'd the failing test on win32,win64 machines in order to see if the ARM buildbot complains again. llvm-svn: 252901
* Clang format a few prior patches (NFC)Teresa Johnson2015-11-021-1/+2
| | | | | | | I had clang formatted my earlier patches using the wrong style. Reformatted with the LLVM style. llvm-svn: 251813
* Support watchOS and tvOS driver optionsTim Northover2015-10-301-0/+2
| | | | | | | | This patch should add support for almost all command-line options and driver tinkering necessary to produce a correct "clang -cc1" invocation for watchOS and tvOS. llvm-svn: 251706
* Revert "[mips] Add support for the new mips-mti-linux toolchain."Vasileios Kalintiris2015-10-301-8/+0
| | | | | | | This reverts commits r251633. I'll investigate the test failure off trunk in order to keep the buildbots clean. llvm-svn: 251698
* [mips] Add support for the new mips-mti-linux toolchain.Vasileios Kalintiris2015-10-291-0/+8
| | | | | | | | | | The original commit in r249137 added the mips-mti-linux toolchain. However, the newly added tests of that commit failed in few buildbots. This commit re-applies the original changes but XFAILs the test file which caused the buildbot failures. This will allow us to examine what's going wrong without having to commit/revert large changes. llvm-svn: 251633
* Recommit "Clang support for -flto=thin."Teresa Johnson2015-10-151-6/+30
| | | | | | | | | This recommits r250398 with fixes to the tests for bot failures. Add "-target x86_64-unknown-linux" to the clang invocations that check for the gold plugin. llvm-svn: 250455
* Revert "Clang support for -flto=thin." (bot failures)Teresa Johnson2015-10-151-30/+6
| | | | | | | | | | | Rolling this back for now since there are a couple of bot failures on the new tests I added, and I won't have a chance to look at them in detail until later this afternoon. I think the new tests need some restrictions on having the gold plugin available. This reverts commit r250398. llvm-svn: 250402
* Clang support for -flto=thin.Teresa Johnson2015-10-151-6/+30
| | | | | | | | | | | | | | | | | | | Summary: Add clang support for -flto=thin option, which is used to set the EmitFunctionSummary code gen option on compiles. Add -flto=full as an alias to the existing -flto. Add tests to check for proper overriding of -flto variants on the command line, and convert grep tests to FileCheck. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, cfe-commits Differential Revision: http://reviews.llvm.org/D11908 llvm-svn: 250398
* Bring back r250262: PS4 toolchainFilipe Cabecinhas2015-10-141-0/+3
| | | | | | | | | | | | | | There was a minor problem with a test. Sorry for the noise yesterday. This patch adds missing pieces to clang, including the PS4 toolchain definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D13482 llvm-svn: 250293
* Revert-to-green r250262 (PS4 toolchain patch)Sean Silva2015-10-141-3/+0
| | | | | | | It is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast e.g. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362 llvm-svn: 250273
* I took care of the build problem in the commit 250252.Ekaterina Romanova2015-10-141-0/+3
| | | | | | | | | | | | | | Resubmitting the patch. This patch adds missing pieces to clang, including the PS4 toolchain definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D13482 llvm-svn: 250262
* reverting my patch, cause build problemsEkaterina Romanova2015-10-141-3/+0
| | | | llvm-svn: 250257
* This patch adds missing pieces to clang, including the PS4 toolchainEkaterina Romanova2015-10-131-0/+3
| | | | | | | | | | | definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D13482 llvm-svn: 250252
* [Driver] Use the parent_path of the clang executable as the default InstalledDirBenjamin Kramer2015-10-131-0/+1
| | | | | | | | This is what most people want anyways. Clang -cc1's main() will override this but for other tools this is the most sensible default and avoids some work. llvm-svn: 250164
* [VFS] Port driver tool chains to VFS.Benjamin Kramer2015-10-071-2/+8
| | | | | | | There are still some loose ends here but it's sufficient so we can detect GCC headers that are inside of a VFS. llvm-svn: 249556
* Remove support for the mips-mti-linux toolchain.Vasileios Kalintiris2015-10-051-8/+0
| | | | | | | There are two remaining buildbot failures that we'll have to investigate before submitting this again. llvm-svn: 249298
* Re-commit "Add support for the new mips-mti-linux toolchain."Vasileios Kalintiris2015-10-051-0/+8
| | | | | | | | | | | r249137 added support for the new mips-mti-linux toolchain. However, the new tests of that commit, broke some buildbots because they didn't use the correct regular expressions to capture the filename of Clang & LLD. This commit re-applies the changes of r249137 and fixes the tests in r249137 in order to match the filenames of the Clang and LLD executable. llvm-svn: 249294
* Revert "Add support for the new mips-mti-linux toolchain."Vasileios Kalintiris2015-10-021-8/+0
| | | | | | | This reverts commit r249137 because it broke the Windows buildbots and a Linux buildbot for LLD. llvm-svn: 249141
* Add support for the new mips-mti-linux toolchain.Vasileios Kalintiris2015-10-021-0/+8
| | | | | | | | | | | | | | | | | | | | Summary: This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld, libcxx, etc. Because of this, it doesn't require neither an existing GCC installation nor a GNU environment. Ideally, in a follow-up patch we would like to add a new --{llvm|clang}-toolchain option (similar to --gcc-toolchain) in order to allow the use of this toolchain with independent Clang builds. For the time being, we use the --sysroot option just to test the correctness of the paths generated by the driver. Reviewers: atanasyan, dsanders, rsmith Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits Differential Revision: http://reviews.llvm.org/D13340 llvm-svn: 249137
* Revert "This patch adds missing pieces to clang, including the PS4 toolchain ↵Greg Bedwell2015-09-251-3/+0
| | | | | | | | definition, added warnings, PS4 defaults, and Driver changes needed for our compiler." This reverts commit r248546 to get our bot green again while we discuss the best way forward. llvm-svn: 248578
* This patch adds missing pieces to clang, including the PS4 toolchainEkaterina Romanova2015-09-241-0/+3
| | | | | | | | | | | definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D11279 llvm-svn: 248546
* Drop useless const in for-range loops.Benjamin Kramer2015-09-241-2/+2
| | | | | | | | StringRefs always point to immutable memory so the const doesn't add value here. Also quiets clang's -Wrange-loop-analysis which warns about the implicit copying. llvm-svn: 248496
OpenPOWER on IntegriCloud