summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/MSVC.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add Windows Control Flow Guard checks (/guard:cf).Andrew Paverd2019-10-281-0/+22
| | | | | | | | | | | | | | | | | | | Summary: A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on indirect function calls, using either the check mechanism (X86, ARM, AArch64) or or the dispatch mechanism (X86-64). The check mechanism requires a new calling convention for the supported targets. The dispatch mechanism adds the target as an operand bundle, which is processed by SelectionDAG. Another pass (CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as required by /guard:cf. This feature is enabled using the `cfguard` CC1 option. Reviewers: thakis, rnk, theraven, pcc Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65761
* [MSVC] Automatically add atlmfc folder to include and libpath.Zachary Turner2019-10-101-1/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D68736 llvm-svn: 374443
* [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
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [MSVC] If unable to find link.exe from a MSVC installation, look for ↵Martin Storsjo2019-04-191-2/+12
| | | | | | | | | | | | | | | | link.exe next to cl.exe Previously, if the MSVC installation isn't detected properly, clang will later just fail to execute link.exe. This improves using clang in msvc mode on linux, where one intentionally might not want to point clang to the MSVC installation itself (which isn't executable as such), but where a link.exe named wine wrapper is available in the path next to a cl.exe named wine wrapper. Differential Revision: https://reviews.llvm.org/D60094 llvm-svn: 358778
* [MSVC] Use the correct casing of HostX64/HostX86Martin Storsjo2019-04-181-2/+2
| | | | | | | | | If accessing the MSVC installation root directly on a case sensitive filesystem, these details matter. Differential Revision: https://reviews.llvm.org/D60627 llvm-svn: 358662
* [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
* [clang-cl] support /Oy- on aarch64Martin Storsjo2019-02-071-4/+4
| | | | | | | | | | MSVC supports /Oy- on aarch64, so clang-cl should too. Patch by Nathan Froyd! Differential Revision: https://reviews.llvm.org/D57838 llvm-svn: 353402
* [Driver] Don't pass default value to getCompilerRTArgStringPetr Hosek2019-01-211-1/+1
| | | | | | | | Using static library is already a default. Differential Revision: https://reviews.llvm.org/D56043 llvm-svn: 351710
* 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
* Update Microsoft name mangling scheme for exception specifiers in the type ↵Reid Kleckner2018-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
* [clang-cl] Do not allow using both /Zc:dllexportInlines- and /fallback flagTakuto Ikuta2018-11-131-6/+0
| | | | | | | | | | | | | | Summary: /Zc:dllexportInlines with /fallback may cause unexpected linker error. It is better to disallow compile rather than warn for this combination. Reviewers: hans, thakis Reviewed By: hans Subscribers: cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D54426 llvm-svn: 346733
* [clang-cl] Add warning for /Zc:dllexportInlines- when the flag is used with ↵Takuto Ikuta2018-11-091-0/+6
| | | | | | | | | | | | | | | | | | /fallback Summary: This is followup of https://reviews.llvm.org/D51340 Reviewers: hans, thakis Reviewed By: hans Subscribers: cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D54298 llvm-svn: 346491
* [AArch64] [Windows] Emit unwind tables by default.Eli Friedman2018-10-311-5/+5
| | | | | | | | | Unwind tables are necessary even in code that doesn't support exceptions. The tables are used for setjmp(), and by debuggers. Differential Revision: https://reviews.llvm.org/D53618 llvm-svn: 345781
* [clang-cl] Provide separate flags for all the /O variantsHans Wennborg2018-09-251-0/+1
| | | | | | | | | | | | | | | This provides better help text in "clang-cl /?". Also it cleans things up a bit: previously "/Od" could be handled either as a separate flag aliased to "-O0", or by the main optimization flag processing in TranslateOptArg. With this patch, all the flags get aliased back to /O so they're handled by TranslateOptArg. Thanks to Nico for the idea! Differential revision: https://reviews.llvm.org/D52266 llvm-svn: 342977
* Reland r341390 clang-cl: Pass /Brepro to linker if it was passed to the compilerNico Weber2018-09-071-0/+9
| | | | | | | | | | The test was missing '--' on mac as pointed out by -Wslash-u-filename: <stdin>:5:69: note: possible intended match here clang: warning: '/Users/thakis/src/llvm-mono/clang/test/Driver/msvc-link.c' treated as the '/U' option [-Wslash-u-filename] Differential Revision: https://reviews.llvm.org/D51635 llvm-svn: 341654
* Reverting r 341390 because it is causing test failures on GreenDragon.A Bergen2018-09-061-9/+0
| | | | | | http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/52810/ llvm-svn: 341560
* clang-cl: Pass /Brepro to linker if it was passed to the compilerNico Weber2018-09-041-0/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D51635 llvm-svn: 341390
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-301-0/+13
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 341082
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-291-13/+0
| | | | | | This reverts r340949 due to bot breakage again. llvm-svn: 340954
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-291-0/+13
| | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340949
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-281-13/+0
| | | | | | This reverts commit r340860 due to failing tests. llvm-svn: 340867
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-0/+13
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* clang-cl: Postpone Wmsvc-not-found emission until link.exe gets used.Nico Weber2018-07-171-2/+3
| | | | | | | | | | | | | | | | | Wmsvc-not-found was added in r297851 to help diagnose why link.exe can't be executed. However, it's emitted even when using -fuse-ld=lld, and in cross builds there's no way to get rid of the warning other than disabling it. Instead, emit it when we look up link.exe and it ends up not being executable. That way, when passing -fuse-ld=lld it will never be printed. It will also not be printed if we find link.exe on PATH. (We might want to eventually default to lld one day, at least when running on a non-Win host, but that's for another day.) Fixes PR38016. llvm-svn: 337290
* Implement CFI for indirect calls via a member function pointer.Peter Collingbourne2018-06-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to CFI on virtual and indirect calls, this implementation tries to use program type information to make the checks as precise as possible. The basic way that it works is as follows, where `C` is the name of the class being defined or the target of a call and the function type is assumed to be `void()`. For virtual calls: - Attach type metadata to the addresses of function pointers in vtables (not the functions themselves) of type `void (B::*)()` for each `B` that is a recursive dynamic base class of `C`, including `C` itself. This type metadata has an annotation that the type is for virtual calls (to distinguish it from the non-virtual case). - At the call site, check that the computed address of the function pointer in the vtable has type `void (C::*)()`. For non-virtual calls: - Attach type metadata to each non-virtual member function whose address can be taken with a member function pointer. The type of a function in class `C` of type `void()` is each of the types `void (B::*)()` where `B` is a most-base class of `C`. A most-base class of `C` is defined as a recursive base class of `C`, including `C` itself, that does not have any bases. - At the call site, check that the function pointer has one of the types `void (B::*)()` where `B` is a most-base class of `C`. Differential Revision: https://reviews.llvm.org/D47567 llvm-svn: 335569
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-2/+2
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* IWYU for llvm-config.h in clang. See r331124 for details.Nico Weber2018-04-301-1/+0
| | | | llvm-svn: 331177
* Remove unnecessary indirection. No behavior change.Nico Weber2018-04-301-12/+6
| | | | llvm-svn: 331176
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-271-2/+2
| | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 331069
* [msvc] Allow MSVC toolchain driver to find the aarch64 / arm64 cross-compiler.Reid Kleckner2018-03-051-0/+6
| | | | | | | | | | | | | | | Starting with the Fall Creators Update, Windows 10 Desktop can run on machines that are powered by aarch64 processors. Microsoft call the aarch64 architecture "arm64". This patch maps ArchType::aarch64 to "arm64" to allow the MSVC toolchain driver to find the aarch64 / arm64 cross-compiler. Patch by Chris January Differential Revision: https://reviews.llvm.org/D44087 llvm-svn: 326744
* 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
* [MS] Raise the default value of _MSC_VER to 1911, which is VS 2017Reid Kleckner2017-10-061-3/+2
| | | | | | | | | | | | | | | | Summary: This raises our default past 1900, which controls whether char16_t is a builtin type or not. Implements PR34243 Reviewers: hans Subscribers: STL_MSFT, rsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D38646 llvm-svn: 315107
* Cleanup and generalize -shared-libasan.Evgeniy Stepanov2017-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: * Rename -shared-libasan to -shared-libsan, keeping the old name as alias. * Add -static-libsan for targets that default to shared. * Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there. * Support libclang_rt.ubsan_standalone as a shared library. Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers. I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers are not compatible with each other, and each link has basically a single shared/static choice. Reviewers: vitalybuka, kcc, rsmith Subscribers: srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D38525 llvm-svn: 315015
* [clang-cl] Claim ignored /O[12xd] argumentsReid Kleckner2017-10-031-20/+20
| | | | | | Fixes PR34809 llvm-svn: 314743
* [Driver] Recognize DevDiv internal builds of MSVC, with a different ↵Stephan T. Lavavej2017-08-211-24/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory structure. This is a reasonably non-intrusive change, which I've verified works for both x86 and x64 DevDiv-internal builds. The idea is to change `bool IsVS2017OrNewer` into a 3-state `ToolsetLayout VSLayout`. Either a build is DevDiv-internal, released VS 2017 or newer, or released VS 2015 or older. When looking at the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`, `"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build. After we get past the directory structure validation, we use this knowledge to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()` uses that. It also knows that DevDiv-internal builds have an `"inc"` subdirectory instead of `"include"`. This may still not be the "right" fix in any sense, but I believe that it's non-intrusive in the sense that if the special directory names aren't found, no codepaths are affected. (`ToolsetLayout::OlderVS` and `ToolsetLayout::VS2017OrNewer` correspond to `IsVS2017OrNewer` being `false` or `true`, respectively.) I searched for all references to `IsVS2017OrNewer`, which are places where Clang cares about VS's directory structure, and the only one that isn't being patched is some logic to deal with cross-compilation. I'm fine with that not working for DevDiv-internal builds for the moment (we typically test the native compilers), so I added a comment. Fixes D36860. llvm-svn: 311391
* [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
* [Driver] Don't force .exe suffix for lldShoaib Meenai2017-06-061-3/+1
| | | | | | | | | | | When cross-compiling to Windows using lld, we want the driver to invoke it as lld-link rather than lld-link.exe. On Windows, the LLVM fs functions take care of adding the .exe suffix where necessary, so we can just drop the addition in the toolchain entirely. Differential Revision: https://reviews.llvm.org/D33923 llvm-svn: 304761
* clang-cl: Fix path-based MSVC version detectionHans Wennborg2017-05-171-2/+9
| | | | | | | | | The code wasn't taking the architecture-specific subdirectory into account. Differential Revision: https://reviews.llvm.org/D33258 llvm-svn: 303267
* [clang-cl] Fix cross-compilation with MSVC 2017.Zachary Turner2017-03-171-2/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang-cl works best when the user runs vcvarsall to set up an environment before running, but even this is not enough on VC 2017 when cross compiling (e.g. using an x64 toolchain to target x86, or vice versa). The reason is that although clang-cl itself will have a valid environment, it will shell out to other tools (such as link.exe) which may not. Generally we solve this through adding the appropriate linker flags, but this is not enough in VC 2017. The cross-linker and the regular linker both link against some common DLLs, but these DLLs live in the binary directory of the native linker. When setting up a cross-compilation environment through vcvarsall, it will add *both* directories to %PATH%, so that when cl shells out to any of the associated tools, those tools will be able to find all of the dependencies that it links against. If you don't do this, link.exe will fail to run because the loader won't be able to find all of the required DLLs that it links against. To solve this we teach the driver how to spawn a process with an explicitly specified environment. Then we modify the PATH before shelling out to subtools and run with the modified PATH. Patch by Hamza Sood Differential Revision: https://reviews.llvm.org/D30991 llvm-svn: 298098
* Don't use MSVC Setup Api on MinGW.Zachary Turner2017-03-151-1/+6
| | | | llvm-svn: 297861
* Update clang-cl driver for MSVC 2017.Zachary Turner2017-03-151-238/+356
| | | | | | | | | | | | | | | | | 2017 changes the way you find an installed copy of Visual Studio as well as its internal directory layout. As a result, clang-cl was unable to find VS2017 even when you had run vcvarsall to set up a toolchain environment. This patch updates everything for 2017 and cleans up the way we handle a tiered search a la environment -> installation -> PATH for which copy of Visual Studio to bind to. Patch originally by Hamza Sood, with some fixups for landing. Differential Revision: https://reviews.llvm.org/D30758 llvm-svn: 297851
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+1233
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