summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/CrossWindows.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-2/+2
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [asan] Add gcc 8's driver option -fsanitize=pointer-compare and ↵Pierre Gousseau2019-04-121-0/+2
| | | | | | | | | | | | -fsanitize=pointer-substract. Disabled by default as this is still an experimental feature. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D59221 llvm-svn: 358285
* Fix file headers. NFCFangrui Song2019-03-011-1/+1
| | | | llvm-svn: 355176
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Consistently make llvm::opt::ArgStringList usage explicit to try and appease ↵Simon Pilgrim2018-10-121-0/+1
| | | | | | MSVC 2015 buildbots. NFCI. llvm-svn: 344398
* [MinGW, CrossWindows] Allow passing -static together with -sharedMartin Storsjo2018-02-271-1/+2
| | | | | | | | | In these combinations, link a DLL as usual, but pass -Bstatic instead of -Bdynamic to indicate prefering static libraries. Differential Revision: https://reviews.llvm.org/D43811 llvm-svn: 326235
* Driver: remove support for libstdc++ from CrossWindowsSaleem Abdulrasool2017-09-221-34/+3
| | | | | | | This code path is entirely untested and not really maintained. The expected use here is with libc++ only. llvm-svn: 313954
* [AArch64] Add support for a MinGW AArch64 targetMartin Storsjo2017-08-131-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D36364 llvm-svn: 310798
* [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
* Introduce -nostdlib++ flag to disable linking the C++ standard library.Nico Weber2017-07-251-2/+1
| | | | | | | | | | | | | | | 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
* Driver: honor -nostdinc and -isystem-after on CrossWindowsSaleem Abdulrasool2017-06-301-4/+10
| | | | | | | | | | This changes CrossWindows to look for -nostdinc instead of -nostdlibinc. In addition, fixes a bug where -isystem-after options would be dropped when called with -nostdinc. Patch by Dave Lee! llvm-svn: 306829
* Driver: only inject libstdc++ paths when needed on CrossWindowsSaleem Abdulrasool2017-05-041-1/+1
| | | | | | | | When building with libc++ don't bother with injecting the libstdc++ search paths into the linker search path. This will make it easier to switch between ld and lld. llvm-svn: 302184
* Toolchains: remove crtbegin on xwindowsSaleem Abdulrasool2017-04-071-9/+0
| | | | | | | | | | crtbegin is not really a proper windows support thing. This was duplicated when the toolchain was initially built. If the injection of crtbegin is needed, it can be done via the `/include` directive. Furthermore, since `-fPIC` doesnt make sense on PE/COFF, crtbegin and crtbeginS dont really need to be different. llvm-svn: 299800
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+318
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
OpenPOWER on IntegriCloud