summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChain.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [OpenMP] Add flag for specifying the target device architecture for OpenMP ↵Gheorghe-Teodor Bercea2017-08-071-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | device offloading Summary: OpenMP has the ability to offload target regions to devices which may have different architectures. A new -fopenmp-target-arch flag is introduced to specify the device architecture. In this patch I use the new flag to specify the compute capability of the underlying NVIDIA architecture for the OpenMP offloading CUDA tool chain. Only a host-offloading test is provided since full device offloading capability will only be available when [[ https://reviews.llvm.org/D29654 | D29654 ]] lands. Reviewers: hfinkel, Hahnfeld, carlo.bertolli, caomhin, ABataev Reviewed By: hfinkel Subscribers: guansong, cfe-commits Tags: #openmp Differential Revision: https://reviews.llvm.org/D34784 llvm-svn: 310263
* [Driver] Error if ARM mode was selected explicitly for M-profile CPUs.Florian Hahn2017-08-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: M-class profiles do not support ARM execution mode, so providing -marm/-mno-thumb does not make sense in combination with -mcpu/-march options that support the M-profile. This is a follow-up patch to D35569 and it seemed pretty clear that we should emit an error in the driver in this case. We probably also should warn/error if the provided -mcpu/-march options do not match, e.g. -mcpu=cortex-m0 -march=armv8-a is invalid, as cortex-m0 does not support armv8-a. But that should be a separate patch I think. Reviewers: echristo, richard.barton.arm, rengolin, labrinea, charles.baylis Reviewed By: rengolin Subscribers: aemerson, javed.absar, kristof.beyls, cfe-commits Differential Revision: https://reviews.llvm.org/D35826 llvm-svn: 310047
* [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.Akira Hatanaka2017-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a bug where clang/llvm doesn't emit an unwind table for a function when it is marked noexcept. Without this patch, the following code terminates with an uncaught exception on ARM64: int foo1() noexcept { try { throw 0; } catch (int i) { return 0; } return 1; } int main() { return foo1(); } rdar://problem/32411865 Differential Revision: https://reviews.llvm.org/D35693 llvm-svn: 310006
* Update to use enum classes for various ARM *Kind enumsFlorian Hahn2017-07-271-1/+1
| | | | | | | | | | | | | | Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
* Introduce -nostdlib++ flag to disable linking the C++ standard library.Nico Weber2017-07-251-0/+8
| | | | | | | | | | | | | | | Projects that want to statically link their own C++ standard library currently need to pass -nostdlib or -nodefaultlibs, which also disables linking of the builtins library, -lm, and so on. Alternatively, they could use `clang` instead of `clang++`, but that already disables implicit addition of -lm on some toolchains. Add a dedicated flag -nostdlib++ that disables just linking of libc++ / libstdc++. This is analogous to -nostdinc++. https://reviews.llvm.org/D35780 llvm-svn: 308997
* [OpenMP] Extend CLANG target options with device offloading kind.Gheorghe-Teodor Bercea2017-07-061-3/+3
| | | | | | | | | | | | | | Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain. Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld Reviewed By: hfinkel Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits Differential Revision: https://reviews.llvm.org/D29647 llvm-svn: 307272
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add arch-specific directory to search pathPirama Arumuga Nainar2017-03-031-0/+13
| | | | | | | | | | | | | | | | | Summary: This change adds an arch-specific subdirectory in <ResourceDir>/lib/<OS> to the linker search path. This path also gets added as '-rpath' for native compilation if a runtime is linked in as a shared object. This allows arch-specific libraries to be installed alongside clang. Reviewers: danalbert, cbergstrom, javed.absar Subscribers: srhines Differential Revision: https://reviews.llvm.org/D30015 llvm-svn: 296927
* [Driver] Allow setting the default linker during buildPetr Hosek2016-12-141-24/+22
| | | | | | | | | 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
* [Driver] Simplify ToolChain::GetCXXStdlibType (NFC)Jonas Hahnfeld2016-12-121-34/+13
| | | | | | | | | | I made the wrong assumption that execution would continue after an error Diag which led to unneeded complex code. This patch aligns with the better implementation of ToolChain::GetRuntimeLibType. Differential Revision: https://reviews.llvm.org/D25669 llvm-svn: 289422
* Refactor how the MSVC toolchain searches for a compatibility version.David L. Jones2016-12-071-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVC toolchain and Clang driver combination currently uses a fairly complex sequence of steps to determine the MS compatibility version to pass to cc1. There is some oddness in this sequence currently, with some code which inspects flags in the toolchain, and some code which inspects the triple and local environment in the driver code. This change is an attempt to consolidate most of this logic so that Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the split, so any suggestions are welcome. There are a few things you might want to watch for for specifically: - On all platforms, if MSVC compatibility flags are provided (and valid), use those. - The fallback sequence should be the same as before, but is now consolidated into MSVCToolChain::getMSVCVersion: - Otherwise, try to use the Triple. - Otherwise, on Windows, check the executable. - Otherwise, on Windows or with --fms-extensions, default to 18. - Otherwise, we can't determine the version. - MSVCToolChain::ComputeEffectiveTriple no longer calls the base ToolChain::ComputeEffectiveClangTriple. The only thing it would change for Windows the architecture, which we don't care about for the compatibility version. - I'm not sure whether this is philosophically correct (but it should be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not). - Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look like the effective triple was always being used previously anyhow. Reviewers: hans, compnerd, llvm-commits, rnk Subscribers: amccarth Differential Revision: https://reviews.llvm.org/D27477 llvm-svn: 288998
* [cfi] Enable cfi-icall on ARM and AArch64.Evgeniy Stepanov2016-11-111-0/+2
| | | | llvm-svn: 286613
* [Driver][OpenMP] Add support to create jobs for bundling actions.Samuel Antao2016-10-271-2/+7
| | | | | | | | | | | | Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21856 llvm-svn: 285325
* [Driver][OpenMP] Update actions builder to create unbundling action when ↵Samuel Antao2016-10-271-0/+1
| | | | | | | | | | | | | | | | | necessary. Summary: Each time that offloading support is requested by the user and the input file is not a source file, an action `OffloadUnbundlingAction` is created to signal that the input file may contain bundles, so that the proper tool is then invoked to attempt to extract the components of the bundle. This patch adds the logic to create that action in offload action builder. The job creation for the new action will be proposed in a separate patch. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21853 llvm-svn: 285324
* [Driver][OpenMP] Update actions builder to create bundling action when ↵Samuel Antao2016-10-271-0/+4
| | | | | | | | | | | | | | | | | necessary. Summary: In order to save the user from dealing with multiple output files (for host and device) while using separate compilation, a new action `OffloadBundlingAction` is used when the last phase is not linking. This action will then result in a job that uses the proposed bundling tool to create a single preprocessed/IR/ASM/Object file from multiple ones. The job creation for the new action will be proposed in a separate patch. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21852 llvm-svn: 285323
* Driver: use StringRef instead of raw pointer in lookupTypeForExtension() (NFC)Mehdi Amini2016-10-071-1/+1
| | | | llvm-svn: 283611
* Revert "Driver: use the canonical static library naming"Saleem Abdulrasool2016-08-311-3/+3
| | | | | | | | This breaks chromium and its unclear if this is actually a modern convention. This reverts SVN r280169. llvm-svn: 280281
* Driver: use the canonical static library namingSaleem Abdulrasool2016-08-301-3/+3
| | | | | | | | | | On Windows, static libraries are named lib<name>.lib while import libraries are named <name>.lib. Use the appropriate naming on itanium and msvc environments. This is setup properly so that if a dynamic builtins is used on Windows, it would do the right thing, although this is not currently wired through the driver (i.e. there is no equivalent to -{shared,static}-gcc). llvm-svn: 280169
* [Driver] Enable CFI for WebAssemblyDerek Schuff2016-08-081-1/+3
| | | | | | | | | | | Since CFI support has landed in the WebAssembly backend, enable it in the frontend driver. Patch by Dominic Chen Differential Revision: https://reviews.llvm.org/D23244 llvm-svn: 278051
* Retry: [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-271-1/+2
| | | | | | | | | | | | | | | | 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-30/+22
| | | | | | | 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
* [ARM] Pass thumb as architecture to the underlying tools, when targeting windowsRenato Golin2016-07-271-1/+3
| | | | | | | | This makes sure that the thumb section flag gets set by the assembler. Patch by Martin Storsjö. llvm-svn: 276869
* Support setting default value for -rtlib at build timeJonas Hahnfeld2016-07-271-9/+13
| | | | | | | | | | | | | | | | | This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
* Update description for CLANG_DEFAULT_CXX_STDLIB and add comment. NFCJonas Hahnfeld2016-07-251-0/+2
| | | | | | | We agreed to call it "platform default" instead of "architecture default". (see D17286) llvm-svn: 276618
* [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-181-22/+30
| | | | | | | | | | 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
* [NFC] Header cleanupMehdi Amini2016-07-181-3/+3
| | | | | | | | | | 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-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Compilation for Intel MCU (Part 2/3)Andrey Turetskiy2016-06-161-0/+3
| | | | | | | | | | | | 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
* Make FreeBSD and NetBSD use CLANG_DEFAULT_CXX_STDLIBJonas Hahnfeld2016-03-141-3/+10
| | | | | | | | | Also introduce -stdlib=platform to override the configured value and use it to make the tests always pass. Differential Revision: http://reviews.llvm.org/D17286 llvm-svn: 263434
* Accept absolute paths in the -fuse-ld option.Peter Zotov2016-03-091-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | This patch extends the -fuse-ld option to accept a full path to an executable and use it verbatim to invoke the linker. There are generally two reasons to desire this. The first reason relates to the sad truth is that Clang is retargetable, Binutils are not. While any Clang from a binary distribution is sufficient to compile code for a wide range of architectures and prefixed BFD linkers (e.g. installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as cross-compiled libc's (for non-bare-metal targets) are widely available, including on all Debian derivatives, it is impossible to use them together because the -fuse-ld= option allows to specify neither a linker prefix nor a full path to one. The second reason is linker development, both when porting existing linkers to new architectures and when working on a new linker such as LLD. Differential Revision: http://reviews.llvm.org/D17952 llvm-svn: 262996
* Fix remaining Clang-tidy readability-redundant-control-flow warnings; other ↵Eugene Zelenko2016-02-121-1/+0
| | | | | | | | minor fixes. Differential revision: http://reviews.llvm.org/D17218 llvm-svn: 260757
* [CMake] Add option to switch default C++ stdlibJonas Hahnfeld2016-02-121-9/+26
| | | | | | | | | With this option one can optionally override the architecture dependent default library to use if no -stdlib= is provided on compiler invocation. Differential Revision: http://reviews.llvm.org/D15920 llvm-svn: 260662
* Driver: protect from empty -L argsMartell Malone2015-11-261-1/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D12466 llvm-svn: 254117
* Driver: Defer computation of linker path until it is needed.Peter Collingbourne2015-11-201-1/+1
| | | | | | | This allows us to construct Linux toolchains without a valid linker. This is needed for example to build a CUDA device toolchain after r253385. llvm-svn: 253707
* [CUDA] added include paths for both sides of CUDA compilation.Artem Belevich2015-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | | In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
* Add trivial utility to append -L arguments to linker step. NFCDouglas Katzman2015-11-171-0/+6
| | | | llvm-svn: 253350
* Re-recommit: Add support for the new mips-mti-linux toolchain.Vasileios Kalintiris2015-11-121-1/+0
| | | | | | | | 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
* [ARM] Clang gives unintended warning message for 'mthumb' + M-profiles:Alexandros Lamprineas2015-11-051-3/+2
| | | | | | | | | $ clang --target=armv7m-none-eabi -mthumb -march=armv7-m -c test.c clang-3.8: warning: argument unused during compilation: '-mthumb' Differential Revision: http://reviews.llvm.org/D14384 llvm-svn: 252175
* Revert "[mips] Add support for the new mips-mti-linux toolchain."Vasileios Kalintiris2015-10-301-0/+1
| | | | | | | 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-1/+0
| | | | | | | | | | 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
* When running clang with an arm triple such as '--target=thumbv7m-none-eabi'Alexandros Lamprineas2015-10-281-6/+8
| | | | | | | | | | | | that has a thumb only CPU by default (cortex-m3), and when using the assembler, the default thumb state of the CPU does not get passed via the triple to LLVM: $ clang -target thumbv7m-none-eabi -c -v test.s clang -cc1as ... -triple armv7m-none--eabi ... test.s Differential Revision: http://reviews.llvm.org/D14121 llvm-svn: 251507
* clang driver toolchain refactoringXinliang David Li2015-10-221-4/+30
| | | | | | | | | | | | | | In this patch, the file static method addProfileRT is moved to be a virtual member function of base ToolChain class. This allows derived toolchain to override the default behavior easily and make it consistent with Darwin toolchain (a TODO was added for this refactoring - now removed). A new helper method is also introduced to test if instrumentation profile option is turned on or not. Differential Revision: http://reviews.llvm.org/D13326 llvm-svn: 250994
* Roll-back r250822.Angel Garcia Gomez2015-10-201-1/+2
| | | | | | | | | | Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
* Apply modernize-use-default to clang.Angel Garcia Gomez2015-10-201-2/+1
| | | | | | | | | | | | Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
* Use Triple.isAndroid() where possible.Evgeniy Stepanov2015-10-081-2/+1
| | | | llvm-svn: 249751
* [VFS] Port driver tool chains to VFS.Benjamin Kramer2015-10-071-3/+1
| | | | | | | 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-0/+1
| | | | | | | 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-1/+0
| | | | | | | | | | | 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
OpenPOWER on IntegriCloud