summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Move OptionUtils from Basic to DriverYaxun (Sam) Liu2019-12-231-0/+1
| | | | Differential Revision: https://reviews.llvm.org/D71802
* [clang][driver] Add ProfileData to LLVM_LINK_COMPONENTSHeejin Ahn2019-10-311-0/+1
| | | | | | | | | | | | | | Summary: After D68351 we need this to make builds with `-DBUILD_SHARED_LIB=ON` work. Reviewers: tlively Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69699
* [clang][driver] Add basic --driver-mode=flang support for fortranPeter Waller2019-10-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new Flang mode. When in Flang mode, the driver will invoke flang for fortran inputs instead of falling back to the GCC toolchain as it would otherwise do. The behaviour of other driver modes are left unmodified to preserve backwards compatibility. It is intended that a soon to be implemented binary in the flang project will import libclangDriver and run the clang driver in the new flang mode. Please note that since the binary invoked by the driver is under development, there will no doubt be further tweaks necessary in future commits. * Initial support is added for basic driver phases * -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified) * -### tests are added for all of the above * This is more than is supported by f18 so far, which will emit errors for those options which are unimplemented. * A test is added that ensures that clang gives a reasonable error message if flang is not available in the path (without -###). * Test that the driver accepts multiple inputs in --driver-mode=flang. * Test that a combination of C and Fortran inputs run both clang and flang in --driver-mode=flang. * clang/test/Driver/fortran.f95 is fixed to use the correct fortran comment character. Differential revision: https://reviews.llvm.org/D63607
* Add AIX toolchain and basic linker functionalitystevewan2019-10-241-0/+1
| | | | | | | | | | | | | | | | Summary: This patch adds AIX toolchain infrastructure into driver, and enables AIX system linker invocation with some basic functionality support Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L Reviewed By: jasonliu Subscribers: Xiangling_L, jasonliu, ormris, wuzish, nemanjai, mgorny, kbarton, jfb, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68340
* [clang][ifs] Clang Interface Stubs ToolChain plumbing.Puyan Lotfi2019-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Second Landing Attempt: This patch enables end to end support for generating ELF interface stubs directly from clang. Now the following: clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp will product an ELF binary with visible symbols populated. Visibility attributes and -fvisibility can be used to control what gets populated. * Adding ToolChain support for clang Driver IFS Merge Phase * Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain * Adds support for the clang Driver to involve llvm-ifs on ifs files. * Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file instead of the final object format (normally ELF) Differential Revision: https://reviews.llvm.org/D63978 llvm-svn: 374061
* Revert 373538 and follow-ups 373549 and 373552.Nico Weber2019-10-031-1/+0
| | | | | | They break tests on (at least) macOS. llvm-svn: 373556
* [clang][ifs] Clang Interface Stubs ToolChain plumbing.Puyan Lotfi2019-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | | This patch enables end to end support for generating ELF interface stubs directly from clang. Now the following: clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp will product an ELF binary with visible symbols populated. Visibility attributes and -fvisibility can be used to control what gets populated. * Adding ToolChain support for clang Driver IFS Merge Phase * Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain * Adds support for the clang Driver to involve llvm-ifs on ifs files. * Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file instead of the final object format (normally ELF) Differential Revision: https://reviews.llvm.org/D63978 llvm-svn: 373538
* [PowerPC] [Clang] Port MMX intrinsics and basic test cases to PowerQiu Chaofan2019-04-231-0/+1
| | | | | | | | | | | | | | Port mmintrin.h which include x86 MMX intrinsics implementation to PowerPC platform (using Altivec). To make the include process correct, PowerPC's toolchain class is overrided to insert new headers directory (named ppc_wrappers) into the path. Basic test cases for several intrinsic functions are added. The header is mainly developed by Steven Munroe, with contributions from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu. Reviewed By: Jinsong Ji Differential Revision: https://reviews.llvm.org/D59924 llvm-svn: 358949
* [MSP430] Provide a toolchain descriptionAnton Korobeynikov2019-01-151-0/+1
| | | | | | | | | | | | | | | This is an initial implementation for msp430 toolchain including -mmcu option support -mhwmult options support -integrated-as by default The toolchain uses msp430-elf-as as a linker and supports msp430-gcc toolchain tree. Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D56658 llvm-svn: 351228
* [darwin] parse the SDK settings from SDKSettings.json if it exists andAlex Lorenz2018-12-171-0/+1
| | | | | | | | | | | | | | | | | | | | pass in the -target-sdk-version to the compiler and backend This commit adds support for reading the SDKSettings.json file in the Darwin driver. This file is used by the driver to determine the SDK's version, and it uses that information to pass it down to the compiler using the new -target-sdk-version= option. This option is then used to set the appropriate SDK Version module metadata introduced in r349119. Note: I had to adjust the two ast tests as the SDKROOT environment variable on macOS caused SDK version to be picked up for the compilation of source file but not the AST. rdar://45774000 Differential Revision: https://reviews.llvm.org/D55673 llvm-svn: 349380
* Add Hurd target to Clang driver (2/2)Kristina Brooks2018-11-291-0/+1
| | | | | | | | | | | | | | | This adds Hurd toolchain support to Clang's driver in addition to handling translating the triple from Hurd-compatible form to the actual triple registered in LLVM. (Phabricator was stripping the empty files from the patch so I manually created them) Patch by sthibaul (Samuel Thibault) Differential Revision: https://reviews.llvm.org/D54379 llvm-svn: 347833
* NFC: Fix some darwin linker warnings introduced in r338385Erik Pilkington2018-09-271-1/+1
| | | | | | | | | | The darwin linker was complaining about Toolchains/RISCV.cpp and Toolchains/Arch/RISCV.cpp had the same name. Fix is to just rename Toolchains/RISCV.cpp to Toolchains/RISCVToolchain.cpp. Differential revision: https://reviews.llvm.org/D52574 llvm-svn: 343263
* [RISCV] Add driver for riscv32-unknown-elf baremetal targetDavid Bolvansky2018-07-311-0/+1
| | | | | | | | | | | | | | | | | Summary: This patch adds a driver for the baremetal RISC-V target (i.e. riscv32-unknown-elf). For reference, D39963 added basic target info and added support for riscv32-linux-unknown-elf. Patch by: asb (Alex Bradbury) Reviewers: efriedma, phosek, apazos, espindola, mgrang Reviewed By: mgrang Subscribers: jrtc27, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, emaste, mgorny, arichardson, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, cfe-commits Differential Revision: https://reviews.llvm.org/D46822 llvm-svn: 338385
* Add HIP toolchainYaxun Liu2018-05-301-0/+1
| | | | | | | | | | | | | | This patch adds HIP toolchain to support HIP language mode. It includes: Create specific compiler jobs for HIP. Choose specific libraries for HIP. With contribution from Greg Rodgers. Differential Revision: https://reviews.llvm.org/D45212 llvm-svn: 333484
* [RISCV] Add the RISCV target and compiler driverAlex Bradbury2018-01-111-0/+1
| | | | | | | | | As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
* Remove Bitrig: Clang ChangesErich Keane2017-07-211-1/+0
| | | | | | | | Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned. Differential Revision: https://reviews.llvm.org/D35708 llvm-svn: 308797
* Add support for Ananas platformEd Schouten2017-06-251-0/+1
| | | | | | | | | | | | | | | | | Ananas is a home-brew operating system, mainly for amd64 machines. After using GCC for quite some time, it has switched to clang and never looked back - yet, having to manually patch things is annoying, so it'd be much nicer if this was in the official tree. More information: https://github.com/zhmu/ananas/ https://rink.nu/projects/ananas.html Submitted by: Rink Springer Differential Revision: https://reviews.llvm.org/D32936 llvm-svn: 306239
* Update libdeps to add BinaryFormat, introduced in r304864.NAKAMURA Takumi2017-06-071-0/+1
| | | | llvm-svn: 304869
* Don't defer to the GCC driver for linking arm-baremetalJonathan Roelofs2017-05-251-0/+1
| | | | | | | | | | | | | | | Also comes with a cmake cache for building the runtime bits: $ cmake <normal cmake flags> \ -DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \ -DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \ -DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \ -C /path/to/clang/cmake/caches/BaremetalARM.cmake \ /path/to/llvm https://reviews.llvm.org/D33259 llvm-svn: 303873
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Driver/ToolChains: Mips -> MipsLinuxKonstantin Zhuravlyov2017-03-081-1/+1
| | | | | | | | | - Mips is architecture, not a toolchain - Might help eliminate the confusion in the future by not having header files with the same name Differential Revision: https://reviews.llvm.org/D30753 llvm-svn: 297312
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-12/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Driver] Move architecture-specific free helper functions to their own files.David L. Jones2017-02-241-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch moves helper functions that are CPU-specific out of Driver.cpp and to separate implementation files. The new files are named for the architecture, e.g. ARMArch.cpp. The next step after this will be to move OS-specific code, which I expect will include many of the tool implementations, to similarly separate files. Some CPU-specific functions are not being moved just yet. In cases where the only caller is the platform-specific tools, I plan to move them together. An example is Hexagon, where the only caller of the architecture-specific functions are the tools themselves. (I'm happy to revise this choice, it just seems like less churn to me.) This does mean that some functions which were previously static are now exposed through the library header Driver.h. Reviewers: rsmith, javed.absar Subscribers: aemerson, danalbert, srhines, dschuff, jyknight, nemanjai, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30315 llvm-svn: 296056
* [Driver] Refactor distro detection & classification as a separate APIMichal Gorny2016-11-281-0/+1
| | | | | | | | | | | | Refactor the Distro enum along with helper functions into a full-fledged Distro class, inspired by llvm::Triple, and make it a public API. The new class wraps the enum with necessary comparison operators, adding the convenience Is*() methods and a constructor performing the detection. The public API is needed to run the unit tests (D25869). Differential Revision: https://reviews.llvm.org/D25949 llvm-svn: 288060
* MSVCToolChain.cpp: Make version.dll generic for win32.NAKAMURA Takumi2016-05-141-0/+6
| | | | | | | We may consider msvc features may be capable on mingw host, if it can. Consider --host=mingw --target=msvc. llvm-svn: 269557
* Support mingw-w64 and mingw.org toolchains at any install location.Yaron Keren2015-07-021-0/+1
| | | | | | | | | | | | | No more hardcoded paths: clang will use -sysroot as gcc root location if provided. Otherwise, it will search for gcc on the path. If not found it will use the driver installed location. http://reviews.llvm.org/D5268 Patch by Ruben Van Boxem, Martell Malone, Yaron Keren. Reviewed by Reid Kleckner. llvm-svn: 241241
* Driver: add CrossWindowsToolChainSaleem Abdulrasool2014-10-241-0/+1
| | | | | | | | | | | | | | | | | | | | This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
* Driver: rename Windows to MSVCToolChainSaleem Abdulrasool2014-10-221-1/+1
| | | | | | | | This renames the Windows toolchain to MSVCToolChain. This is a preparatory step for adding a CrossWindowsToolChain which uses clang/libc++/(ld/lld) without the standard GCC toolchain lookup. NFC. llvm-svn: 220362
* Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.Alexey Samsonov2014-07-091-1/+0
| | | | | | | | | | | | | | | | Turn llvm::SpecialCaseList into a simple class that parses text files in a specified format and knows nothing about LLVM IR. Move this class into LLVMSupport library. Implement two users of this class: * DFSanABIList in DFSan instrumentation pass. * SanitizerBlacklist in Clang CodeGen library. The latter will be modified to use actual source-level information from frontend (source file names) instead of unstable LLVM IR things (LLVM Module identifier). Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils. No functionality change. llvm-svn: 212643
* cc1as: consolidate option flags with cc1 and eliminate duplicationAlp Toker2014-07-091-2/+0
| | | | | | | | | | The clang -cc1as options are nearly a strict subset of -cc1. Instead of duplicating the definitions and documentation, let's go ahead and share the definitions in a similar way the current handling of combined driver and frontend flags, eliminating some of the vestigial legacy surrounding the assembler subcommand. llvm-svn: 212620
* [CMake] Use LINK_LIBS instead of target_link_libraries().NAKAMURA Takumi2014-02-261-2/+1
| | | | llvm-svn: 202238
* [CMake] Get rid of explicit dependencies to include/clang/*.inc and ↵NAKAMURA Takumi2014-02-211-5/+1
| | | | | | | | | | | | | | | | | | | introduce CLANG_TABLEGEN_TARGETS. This does; - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list. - List of targets is added to LLVM_COMMON_DEPENDS. - all clang libraries and targets depend on generated headers. You might wonder this would be regression, but in fact, this is little loss. - Almost all of clang libraries depend on tblgen'd files and clang-tblgen. - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild. - Each library's dependencies to tblgen'd files might vary along headers' structure. It made hard to track and update *really optimal* dependencies. Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS. llvm-svn: 201842
* Add Multilib selection machineryJonathan Roelofs2014-02-121-0/+1
| | | | | | | | | | | | This patch improves the support for picking Multilibs from gcc installations. It also provides a better approximation for the flags '-print-multi-directory' and '-print-multi-lib'. This reverts r201203 (i.e. re-applying r201202 with small fixes in unittests/CMakeLists.txtto make the build bots happy). review: http://llvm-reviews.chandlerc.com/D2538 llvm-svn: 201205
* Revert 201202Jonathan Roelofs2014-02-121-1/+0
| | | | | | Breaks cmake configure of new unit tests directory llvm-svn: 201203
* Add Multilib selection machineryJonathan Roelofs2014-02-121-0/+1
| | | | | | | | | This patch improves the support for picking Multilibs from gcc installations. It also provides a better approximation for the flags '-print-multi-directory' and '-print-multi-lib'. review: http://llvm-reviews.chandlerc.com/D2538 llvm-svn: 201202
* [CMake] clangDriver: Move LLVM stuff in target_link_library to ↵NAKAMURA Takumi2013-12-091-2/+6
| | | | | | LLVM_LINK_COMPONENTS. llvm-svn: 196798
* Re-apply r188666Alexey Samsonov2013-08-191-0/+1
| | | | llvm-svn: 188675
* Move SanitizerArgs implementation from .h to .cppAlexey Samsonov2013-08-081-0/+1
| | | | llvm-svn: 187972
* [Driver] Refactor clang driver to use LLVM's Option libraryReid Kleckner2013-06-141-4/+1
| | | | | | | | | | | | | | | | | | The big changes are: - Deleting Driver/(Arg|Opt)* - Rewriting includes to llvm/Option/ and re-sorting - 'using namespace llvm::opt' in clang::driver - Fixing the autoconf build by adding option everywhere As discussed in the review, this change includes using directives in header files. I'll make follow up changes to remove those in favor of name specifiers. Reviewers: espindola Differential Revision: http://llvm-reviews.chandlerc.com/D975 llvm-svn: 183989
* clang/lib: [CMake] Update tblgen'd dependencies.NAKAMURA Takumi2012-07-271-0/+1
| | | | llvm-svn: 160851
* clang/lib: [CMake] Reformat, alphabetize lists.NAKAMURA Takumi2012-07-271-1/+1
| | | | llvm-svn: 160850
* Remove a goofy CMake hack and use the standard CMake facilities toChandler Carruth2012-06-211-4/+9
| | | | | | | | | express library-level dependencies within Clang. This is no more verbose really, and plays nicer with the rest of the CMake facilities. It should also have no change in functionality. llvm-svn: 158888
* Zap the /Za compiler switch from MSVC projects, the option is considered ↵Francois Pichet2012-06-061-7/+0
| | | | | | | | harmful even by Microsoft people and clang won't build using the MSVC 2012 RC if not removed. Only 1 minor code change was necessary: can't use cdecl as variable name anymore. llvm-svn: 158063
* Remove AST and Parse from Driver's dependencies.Jordan Rose2012-06-041-1/+1
| | | | llvm-svn: 157933
* Speculatively fix windows cmake builders.Andrew Trick2012-05-021-1/+1
| | | | | | Really just a wild stab in the dark. llvm-svn: 155974
* Unify Options.td and CC1Options.td, in a first step towards unifying the ↵James Molloy2012-05-011-1/+0
| | | | | | | | serialization logic in Frontend and Driver. Reviewed by Eric, Doug and Chandler, and here: http://llvm.org/reviews/r/7/ llvm-svn: 155916
* Delete the driver's HostInfo class. This abstraction just never reallyChandler Carruth2012-01-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | did anything. The two big pieces of functionality it tried to provide was to cache the ToolChain objects for each target, and to figure out the exact target based on the flag set coming in to an invocation. However, it had a lot of flaws even with those goals: - Neither of these have anything to do with the host, or its info. - The HostInfo class was setup as a full blown class *hierarchy* with a separate implementation for each "host" OS. This required dispatching just to create the objects in the first place. - The hierarchy claimed to represent the host, when in fact it was based on the target OS. - Each leaf in the hierarchy was responsible for implementing the flag processing and caching, resulting in a *lot* of copy-paste code and quite a few bugs. - The caching was consistently done based on architecture alone, even though *any* aspect of the targeted triple might change the behavior of the configured toolchain. - Flag processing was already being done in the Driver proper, separating the flag handling even more than it already is. Instead of this, we can simply have the dispatch logic in the Driver which previously created a HostInfo object create the ToolChain objects. Adding caching in the Driver layer is a tiny amount of code. Finally, pulling the flag processing into the Driver puts it where it belongs and consolidates it in one location. The result is that two functions, and maybe 100 lines of new code replace over 10 classes and 800 lines of code. Woot. This also paves the way to introduce more detailed ToolChain objects for various OSes without threading through a new HostInfo type as well, and the accompanying boiler plate. That, of course, was the yak I started to shave that began this entire refactoring escapade. Wheee! llvm-svn: 148950
* Split the Windows toolchain definition into its own file. This isChandler Carruth2011-12-171-0/+1
| | | | | | | | | | | | | | | especially nice as the Windows toolchain needs the windows header files, and has lots of platform specific hooks in it. To facilitate the split, hoist a bunch of file-level static helpers into class-level static helpers. Spiff up their doxygen comments while there as they're now more likely to be looked up via docs. Hopefully, this will be followed by further breaking apart of the toolchain definitions. Most of the large and complex ones should likely live on their own. I'm looking at you Darwin. ;] llvm-svn: 146840
* Fix MSVC build.Michael J. Spencer2011-11-051-0/+8
| | | | llvm-svn: 143770
* CMake: LLVM_NO_RTTI must be obsolete now!NAKAMURA Takumi2011-02-101-2/+0
| | | | llvm-svn: 125275
OpenPOWER on IntegriCloud