summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/MinGW.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MinGW] Implicitly add .exe suffix if not providedMartin Storsjö2019-12-171-1/+13
| | | | | | | | | | | | | | | | | GCC implicitly adds an .exe suffix if it is given an output file name, but the file name doesn't contain a suffix, and there are certain users of GCC that rely on this behaviour (and run into issues when trying to use Clang instead of GCC). And MSVC's cl.exe also does the same (but not link.exe). However, GCC only does this when actually running on windows, not when operating as a cross compiler. As GCC doesn't have this behaviour when cross compiling, we definitely shouldn't introduce the behaviour in such cases (as it would break at least as many cases as this fixes). Differential Revision: https://reviews.llvm.org/D71400
* [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
* [MinGW] Use SEH by default on AArch64Martin Storsjo2019-05-061-2/+3
| | | | | | | | The implementation of SEH is pretty mature at this point. Differential Revision: https://reviews.llvm.org/D61591 llvm-svn: 360081
* [MinGW] Remove some supefluous calls to MakeArgString. NFC.Martin Storsjo2019-04-151-8/+8
| | | | llvm-svn: 358393
* [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
* Revert the r348352 "[clang] - Simplify tools::SplitDebugName."George Rimar2019-03-271-1/+1
| | | | | | | | | This partially reverts the r348352 (https://reviews.llvm.org/D55006) because of https://bugs.llvm.org/show_bug.cgi?id=41161. I did not revert the test case file because it passes fine now. llvm-svn: 357061
* [Driver] Support object files in addition to static and shared libraries in ↵Petr Hosek2019-03-121-2/+2
| | | | | | | | | | | | compiler-rt This change introduces support for object files in addition to static and shared libraries which were already supported which requires changing the type of the argument from boolean to an enum. Differential Revision: https://reviews.llvm.org/D56044 llvm-svn: 355891
* [MinGW] Add the profiling library when necessaryMartin Storsjo2019-02-131-0/+2
| | | | | | | | | Profiling still doesn't seem to work properly, but this at least hooks up the library and eases completing whatever is missing. Differential Revision: https://reviews.llvm.org/D58107 llvm-svn: 353917
* 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
* [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabledMartin Storsjo2018-12-181-0/+6
| | | | | | | | | | | | For targets where SEH exceptions are used by default (on MinGW, only x86_64 so far), -munwind-tables are added automatically. If -fseh-exeptions is enabled on a target where SEH exeptions are availble but not enabled by default yet (aarch64), we need to pass -munwind-tables if -fseh-exceptions was specified. Differential Revision: https://reviews.llvm.org/D55749 llvm-svn: 349452
* [clang] - Simplify tools::SplitDebugName.George Rimar2018-12-051-1/+1
| | | | | | | | | | | | | | | | | | This is an updated version of the D54576, which was reverted. Problem was that SplitDebugName calls the InputInfo::getFilename which asserts if InputInfo given is not of type Filename: const char *getFilename() const { assert(isFilename() && "Invalid accessor."); return Data.Filename; } At the same time at that point, it can be of type Nothing and we need to use getBaseInput(), like original code did. Differential revision: https://reviews.llvm.org/D55006 llvm-svn: 348352
* Revert "[clang] - Simplify tools::SplitDebugName."Jonas Toth2018-11-271-1/+1
| | | | | | | | This reverts commit r347035 as it introduced assertion failures under certain conditions. More information can be found here: https://reviews.llvm.org/rL347035 llvm-svn: 347676
* [clang] - Simplify tools::SplitDebugName.George Rimar2018-11-161-1/+1
| | | | | | | | | | | | | This should be NFC change. SplitDebugName recently started to accept the `Output` that can be used to simplify the logic a bit, also it seems that code in SplitDebugName that uses OPT_fdebug_compilation_dir is simply dead. Differential revision: https://reviews.llvm.org/D54576 llvm-svn: 347035
* [Clang] - Add '-gsplit-dwarf[=split,=single]' version for '-gsplit-dwarf' ↵George Rimar2018-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | option. The DWARF5 specification says(Appendix F.1): "The sections that do not require relocation, however, can be written to the relocatable object (.o) file but ignored by the linker or they can be written to a separate DWARF object (.dwo) file that need not be accessed by the linker." The first part describes a single file split DWARF feature and there is no way to trigger this behavior atm. Fortunately, no many changes are required to keep *.dwo sections in a .o, the patch does that. Differential revision: https://reviews.llvm.org/D52296 llvm-svn: 346837
* [MinGW] Link to correct openmp libraryMartin Storsjo2018-10-231-2/+18
| | | | | | | | Patch by Peiyuan Song! Differential Revision: https://reviews.llvm.org/D53397 llvm-svn: 345003
* [MinGW] Allow using LTO when lld is used as linkerMartin Storsjo2018-10-121-0/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D53195 llvm-svn: 344412
* [MinGW] Allow using ASanMartin Storsjo2018-10-011-3/+26
| | | | | | | | | | | | | | | | | | Linking to ASan for MinGW is similar to MSVC, but MinGW always links the MSVCRT dynamically, so there is only one of the MSVC cases to consider. When linking to a shared compiler runtime library on MinGW, the suffix of the import library is .dll.a. The existing case of .dll as suffix for windows in general doesn't seem correct (since this is used for linking). As long as callers never actually set the Shared flag, the default static suffix of .lib also worked fine for import libraries as well. Differential Revision: https://reviews.llvm.org/D52538 llvm-svn: 343537
* [MinGW] Skip adding default win32 api libraries if -lwindowsapp is specifiedMartin Storsjo2018-07-101-8/+20
| | | | | | | | | | | | | | | | | In this setup, skip adding all the default windows import libraries, if linking to windowsapp (which replaces them, when targeting the windows store/UWP api subset). With GCC, the same is achieved by using a custom spec file, but since clang doesn't use spec files, we have to allow other means of overriding what default libraries to use (without going all the way to using -nostdlib, which would exclude everything). The same approach, in detecting certain user specified libraries and omitting others from the defaults, was already used in SVN r314138. Differential Revision: https://reviews.llvm.org/D49059 llvm-svn: 336655
* [MinGW] Treat any -lucrt* as replacing -lmsvcrtMartin Storsjo2018-07-101-1/+1
| | | | | | | | | | | | | | Since SVN r314138, we check if the user has specified any particular alternative msvcrt/ucrt version, and skip the default -lmsvcrt in those cases. In addition to the existing names checked, we should also treat a plain -lucrt in the same way, mingw-w64 has now added a separate import library named libucrt.a, in addition to libucrtbase.a. Differential Revision: https://reviews.llvm.org/D49054 llvm-svn: 336654
* [MinGW] Try to fix asan testing after r330244Martin Storsjo2018-04-181-6/+5
| | | | | | Twines shouldn't be stored as they can refer to temporaries. llvm-svn: 330277
* [MinGW] Look for a cross sysroot relative to the clang binaryMartin Storsjo2018-04-181-1/+24
| | | | | | | | | If found, prefer this over looking for a similar gcc later in the system path. Differential Revision: https://reviews.llvm.org/D45504 llvm-svn: 330244
* [MinGW] Look for libc++ headers in a triplet prefixed path as wellMartin Storsjo2018-04-121-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | This makes it consistent with libstdc++ and the other default include directories. If these headers are found in both locations and one isn't a symlink to the other, this will cause errors due to libc++ headers having wrapper headers for some standard C headers, wrappers that do #include_next the actual one. If the same libc++ standard C wrapper header exists in more than one include directory before the real system one, the header include guard will stop it from doing another #include_next to pick up the real one, breaking things. As this is a rather uncommon situation, this should be acceptable and toolchain maintainers can adapt accordingly if necessary. Also simplify some of the existing code with a local variable. Differential Revision: https://reviews.llvm.org/D45500 llvm-svn: 329946
* [MinGW, CrossWindows] Allow passing -static together with -sharedMartin Storsjo2018-02-271-13/+12
| | | | | | | | | 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
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a re-apply of r319294. 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 -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: 319297
* Revert "Toolchain: Normalize dwarf, sjlj and seh eh"Martell Malone2017-11-291-5/+2
| | | | | | | | This reverts rL319294. The windows sanitizer does not like seh on x86. Will re apply with None type for x86 llvm-svn: 319295
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] MinGW: Remove custom linker detectionMartell Malone2017-11-041-10/+2
| | | | | | | | | | | | | | | | | | This is a re-apply of rL313082 which was reverted in rL313088 In rL289668 the ability to specify the default linker at compile time was added but because the MinGW driver used custom detection we could not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER. rL289668 added no test cases and the mingw driver was either overlooked or purposefully skipped because it has some custom linker tests Removing them here because they are covered by the generic case. Reviewers: rnk Differntial Revision: https://reviews.llvm.org/D37727 llvm-svn: 317397
* Revert "[ADT] Make Twine's copy constructor private."Zachary Turner2017-10-111-1/+1
| | | | | | | | | | This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5. This is failing due to some code that isn't built on MSVC so I didn't catch. Not immediately obvious how to fix this at first glance, so I'm reverting for now. llvm-svn: 315536
* [ADT] Make Twine's copy constructor private.Zachary Turner2017-10-111-1/+1
| | | | | | | | | | | | | | | | | There's a lot of misuse of Twine scattered around LLVM. This ranges in severity from benign (returning a Twine from a function by value that is just a string literal) to pretty sketchy (storing a Twine by value in a class). While there are some uses for copying Twines, most of the very compelling ones are confined to the Twine class implementation itself, and other uses are either dubious or easily worked around. This patch makes Twine's copy constructor private, and fixes up all callsites. Differential Revision: https://reviews.llvm.org/D38767 llvm-svn: 315530
* [MinGW] Don't link -lmsvcrt if a different msvcrt version is to be linkedMartin Storsjo2017-09-251-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D37530 llvm-svn: 314138
* Revert "[Driver] MinGW: Remove custom linker detection"Martell Malone2017-09-131-2/+10
| | | | | | | | | | | This reverts rL313102 because it still fails some build bot tests. On many linux bots it fails with the following error. error: invalid linker name in argument '-fuse-ld=lld' and on some windows bots also because there is no ld.lld.exe lld-link.exe: warning: ignoring unknown argument: -fuse-ld=lld llvm-svn: 313104
* [Driver] MinGW: Remove custom linker detectionMartell Malone2017-09-131-10/+2
| | | | | | | | | | | | | In rL289668 the ability to specify the default linker at compile time was added but because the MinGW driver used custom detection we could not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER. This is a re-apply of rL313082 which was reverted in rL313088 due to failing buildbot tests. Differential Revision: https://reviews.llvm.org/D37727 llvm-svn: 313102
* Revert "[Driver] MinGW: Remove custom linker detection"Martell Malone2017-09-121-2/+10
| | | | | | This reverts rL313082 llvm-svn: 313088
* [Driver] MinGW: Remove custom linker detectionMartell Malone2017-09-121-10/+2
| | | | | | | | In rL289668 the ability to specify the default linker at compile time was added but because the MinGW driver used custom detection we could not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER. llvm-svn: 313082
* [AArch64] Add support for a MinGW AArch64 targetMartin Storsjo2017-08-131-3/+15
| | | | | | 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: Better detection of mingw-gccMartell Malone2017-04-181-11/+13
| | | | | | | | | | | | | Stop blindly searching for "gcc.exe" on windows. Stop assuming "/usr" on unix, fixes cross compiling. Reviewers: mati865, yaron.keren Subscribers: ismail, rnk Differential revision: https://reviews.llvm.org/D15005 llvm-svn: 300555
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+471
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