summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChain.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 clang cc1 assumes dwarf is the default if none is passed and -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319294
* [Driver] Make the use of relax relocations a per target optionPetr Hosek2017-11-221-0/+4
| | | | | | | | | | | | | The support for relax relocations is dependent on the linker and different toolchains within the same compiler can be using different linkers some of which may or may not support relax relocations. Give toolchains the option to control whether they want to use relax relocations in addition to the existing (global) build system option. Differential Revision: https://reviews.llvm.org/D39831 llvm-svn: 318816
* [OpenMP] Consistently use cubin extension for nvlinkJonas Hahnfeld2017-11-211-0/+4
| | | | | | | | | | | | This was previously done in some places, but for example not for bundling so that single object compilation with -c failed. In addition cubin was used for all file types during unbundling which is incorrect for assembly files that are passed to ptxas. Tighten up the tests so that we can't regress in that area. Differential Revision: https://reviews.llvm.org/D40250 llvm-svn: 318763
* [ARM] For assembler files recognize -Xassembler or -Wa, -mthumbPeter Smith2017-11-201-5/+24
| | | | | | | | | | | | | | | | | | | | | | The Unified Arm Assembler Language is designed so that the majority of assembler files can be assembled for both Arm and Thumb with the choice made as a compilation option. The way this is done in gcc is to pass -mthumb to the assembler with either -Wa,-mthumb or -Xassembler -mthumb. This change adds support for these options to clang. There is no assembler equivalent of -mno-thumb, -marm or -mno-arm so we don't need to recognize these. Ideally we would do all of the processing in CollectArgsForIntegratedAssembler(). Unfortunately we need to change the triple and at that point it is too late. Instead we look for the option earlier in ComputeLLVMTriple(). Fixes PR34519 Differential Revision: https://reviews.llvm.org/D40127 llvm-svn: 318647
* [WebAssembly] Add crt1.o with calling lldSam Clegg2017-10-271-8/+6
| | | | | | | | | Also, for OS unknown targets like wasm, don't include 'unknown' in the library path. This is a fix for rL316719. Differential Revision: https://reviews.llvm.org/D39354 llvm-svn: 316777
* [WebAssembly] Include libclang_rt.builtins in the standard waySam Clegg2017-10-271-1/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D39218 llvm-svn: 316719
* Driver: use ld64.lld when -fuse-ld=lld for darwinMartell Malone2017-10-151-1/+5
| | | | | | | | | | | | | | | | | | | When using lld on macOS the current level of detection between ld and ld64 forces us to rename lld to ld. For ELF targets we have the ld.lld alias so for MACHO we should have ld64.lld so we can use lld without replacing the system compiler. This also solves the additional issue of cross compiling for MACHO where renaming lld to ld with only target ELF. This is the clang driver component change to use this new alias. Reviewers: ruiu, rnk Differential Revision: https://reviews.llvm.org/D38290 llvm-svn: 315867
* [OpenMP] Fix passing of -m arguments correctlyJonas Hahnfeld2017-10-041-61/+55
| | | | | | | | | | The recent fix in D38258 was wrong: getAuxTriple() only returns non-null values for the CUDA toolchain. That is why the now added test for PPC and X86 failed. Differential Revision: https://reviews.llvm.org/D38372 llvm-svn: 314902
* [OpenMP] Fix passing of -m arguments to device toolchainJonas Hahnfeld2017-09-271-6/+9
| | | | | | | | | | | AuxTriple is not set if host and device share a toolchain. Also, removing an argument modifies the DAL which needs to be returned for future use. (Move tests back to offload-openmp.c as they are not related to GPUs.) Differential Revision: https://reviews.llvm.org/D38258 llvm-svn: 314329
* [OpenMP] Fix memory leak when translating argumentsJonas Hahnfeld2017-09-271-3/+5
| | | | | | | | | | Parsing the argument after -Xopenmp-target allocates memory that needs to be freed. Associate it with the final DerivedArgList after we know which one will be used. Differential Revision: https://reviews.llvm.org/D38257 llvm-svn: 314328
* Fix validation of the -mthread-model flag in the Clang driverJonathan Roelofs2017-09-071-5/+0
| | | | | | | | | | | | | The ToolChain class validates the -mthread-model flag in the constructor which doesn't work correctly since the thread model methods are virtual methods. The check is moved into Clang::ConstructJob() when constructing the internal command line. https://reviews.llvm.org/D37496 Patch by: Ian Tessier! llvm-svn: 312748
* Restore clang_rt library name on i686-android.Evgeniy Stepanov2017-08-291-0/+4
| | | | | | | | | | | | | | | | | Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
* Use class to pass information about executable nameSerge Pavlov2017-08-291-19/+22
| | | | | | | | | | | | | Information about clang executable name components, such as target and driver mode, was passes in std::pair. With this change it is passed in a special structure. It improves readability and makes access to this information more convenient. NFC. Differential Revision: https://reviews.llvm.org/D36057 llvm-svn: 311981
* Reland r311836 - [Driver] Use arch type to find compiler-rt libraries (on Linux)Michal Gorny2017-08-281-4/+1
| | | | | | | | | | | | | | | | | | | | Use llvm::Triple::getArchTypeName() when looking for compiler-rt libraries, rather than the exact arch string from the triple. This is more correct as it matches the values used when building compiler-rt (builtin-config-ix.cmake) which are the subset of the values allowed in triples. For example, this fixes an issue when the compiler set for i686-pc-linux-gnu triple would not find an i386 compiler-rt library, while this is the exact arch that is detected by compiler-rt. The same applies to any other i?86 variant allowed by LLVM. This also makes the special case for MSVC unnecessary, since now i386 will be used reliably for all 32-bit x86 variants. Differential Revision: https://reviews.llvm.org/D26796 llvm-svn: 311923
* Revert r311836 - [Driver] Use arch type to find compiler-rt libraries (on Linux)Michal Gorny2017-08-271-1/+4
| | | | | | | This causes a breakage on the Android build bot. Let's revert it until we figure out the correct solution there. llvm-svn: 311861
* [Driver] Use arch type to find compiler-rt libraries (on Linux)Michal Gorny2017-08-261-4/+1
| | | | | | | | | | | | | | | | | | | | Use llvm::Triple::getArchTypeName() when looking for compiler-rt libraries, rather than the exact arch string from the triple. This is more correct as it matches the values used when building compiler-rt (builtin-config-ix.cmake) which are the subset of the values allowed in triples. For example, this fixes an issue when the compiler set for i686-pc-linux-gnu triple would not find an i386 compiler-rt library, while this is the exact arch that is detected by compiler-rt. The same applies to any other i?86 variant allowed by LLVM. This also makes the special case for MSVC unnecessary, since now i386 will be used reliably for all 32-bit x86 variants. Differential Revision: https://reviews.llvm.org/D26796 llvm-svn: 311836
* Fix memory leak in ToolChain::TranslateOpenMPTargetArgsJonas Hahnfeld2017-08-141-1/+5
| | | | | | | rL310433 introduced a code path where DAL is not returned and must be freed. This change allows to run openmp-offload.c when Clang is built with ASan. llvm-svn: 310817
* [Driver] Search compiler-rt paths in -print-file-name=Petr Hosek2017-08-101-3/+8
| | | | | | | | | | | This makes it possible to print the name of compiler-rt libraries by using simply clang -print-file-name=libclang_rt.${runtime}-${arch}.so same as other libraries, without having to know the details of the resource directory organization. Differential Revision: https://reviews.llvm.org/D35820 llvm-svn: 310548
* [OpenMP] Fix bug regarding cubin integration into host binaryGheorghe-Teodor Bercea2017-08-091-1/+3
| | | | | | | | | | when a BindArchAction is used. This is not a functional change. Original Diff: D29654 llvm-svn: 310433
* [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
OpenPOWER on IntegriCloud