summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix first line comment format, NFC.Yaron Keren2015-07-071-2/+1
| | | | llvm-svn: 241594
* Add a comment to explain how the decision to pass feature "+long-calls" is made.Akira Hatanaka2015-07-071-0/+3
| | | | llvm-svn: 241568
* [ARM] Pass subtarget feature "+long-calls" instead of passing backend optionAkira Hatanaka2015-07-071-16/+10
| | | | | | | | | | | | | "-arm-long-calls". This change allows using -mlong-calls/-mno-long-calls for LTO and enabling or disabling long call on a per-function basis. rdar://problem/21529937 Differential Revision: http://reviews.llvm.org/D9414 llvm-svn: 241565
* [Driver] Use llvm::Triple methods to handle -EL and -EB.Benjamin Kramer2015-07-061-12/+6
| | | | | | Add a test for ppc64(le), which wasn't handled before. llvm-svn: 241528
* Support -pthread in mingw toolchain.Yaron Keren2015-07-061-4/+2
| | | | | | "-pthread" appends -lpthread after the object files list passed to the linker. llvm-svn: 241485
* Resubmit "Pass down the -flto option to the -cc1 job" (r239481)Teresa Johnson2015-07-061-0/+4
| | | | | | | | | | | | | | | | | | The patch is the same except for the addition of a new test for the issue that required reverting the dependent llvm commit. --Original Commit Message-- Pass down the -flto option to the -cc1 job, and from there into the CodeGenOptions and onto the PassManagerBuilder. This enables gating the new EliminateAvailableExternally module pass on whether we are preparing for LTO. If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not included as we want to preserve available externally functions for possible link time inlining. llvm-svn: 241467
* Teach mingw toolchain the msys2 mingw-w64 distribution C++ dirs.Yaron Keren2015-07-062-11/+18
| | | | llvm-svn: 241432
* Driver: Remove the Job class. NFCJustin Bogner2015-07-023-33/+16
| | | | | | | | | | | We had a strange relationship here where we made a list of Jobs inherit from a single Job, but there weren't actually any places where this arbitrary nesting was used or needed. Simplify all of this by removing Job entirely and updating all of the users to either work with a JobList or a single Command. llvm-svn: 241310
* Driver: Don't use reserved names. NFCJustin Bogner2015-07-021-6/+4
| | | | llvm-svn: 241309
* Support mingw-w64 and mingw.org toolchains at any install location.Yaron Keren2015-07-026-6/+414
| | | | | | | | | | | | | 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
* Make getArchNameForCompilerRTLib return the right thing on 32-bit Windows. ↵Peter Collingbourne2015-07-021-0/+4
| | | | | | Fixes the tests there. llvm-svn: 241228
* Driver: add support for linking the UBSan runtime library on Windows.Peter Collingbourne2015-07-023-9/+21
| | | | | | | | | | | | | | On Windows the user may invoke the linker directly, so we might not have an opportunity to add runtime library flags to the linker command line. Instead, instruct the code generator to embed linker directive in the object file that cause the required runtime libraries to be linked. We might also want to do something similar for ASan, but it seems to have its own special complexities which may make this infeasible. Differential Revision: http://reviews.llvm.org/D10862 llvm-svn: 241225
* More range-based-for-loopification. NFCDouglas Katzman2015-06-301-13/+8
| | | | llvm-svn: 241106
* [clang-cl] Use /arch: to set the base target CPUReid Kleckner2015-06-301-0/+22
| | | | | | | | | | | | The main effect of this change is that /arch:IA32 will use i386 as the CPU, while clang-cl will continue to default to pentium4 (aka SSE2 plus the usual other features). /arch:AVX and /arch:AVX2 will also now enable the other features available in sandybridge and haswell respectively, which is consistent with MSDN. llvm-svn: 241077
* More range-based for loops. NFCDouglas Katzman2015-06-291-7/+5
| | | | llvm-svn: 240984
* Comment fixes. NFC.Douglas Katzman2015-06-291-2/+2
| | | | | | | | | - Hexagon options were physically next to to ones that had a preceding comment saying "Double dash options", which they aren't. - The 'ld' tool classes are named Linker, not Link. llvm-svn: 240980
* [Driver] x86-64 Windows is always PICDavid Majnemer2015-06-281-2/+6
| | | | | | This fixes PR23963. llvm-svn: 240902
* [PPC]: Fix bug in getMultiarchTriple.Douglas Katzman2015-06-261-18/+22
| | | | | | | | And generally prefer not to restate TargetTriple.str() over and over. Differential Revision: http://reviews.llvm.org/D10605 llvm-svn: 240808
* clang-format some of the files in lib/Driver. NFCDouglas Katzman2015-06-264-1540/+1338
| | | | | | | | | Nothing was hand edited afterward except a few literal strings and comments that were poorly broken. Differential Revision: http://reviews.llvm.org/D10689 llvm-svn: 240791
* [CFI] Diagnose when we CFI in diagnostic mode is unavailable on a toolchain.Alexey Samsonov2015-06-251-1/+17
| | | | | | | | | | | | | | | | | | | | | | | Summary: Namely, we must have proper C++ABI support in UBSan runtime. We don't have a good way to check for that, so just assume that C++ABI support is there whenever -fsanitize=vptr is supported (i.e. only on handful of platforms). Exact diagnostic is also tricky. It's not "cfi" that is unsupported, just the diagnostic mode. So, I suggest to report that "-fno-sanitize-trap=cfi-foobar" is incompatible with a given target toolchain. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10751 llvm-svn: 240716
* Rename local variable CCCPrintActions -> CCCPrintPhases.Douglas Katzman2015-06-251-15/+12
| | | | | | | To match the '-ccc-print-phases' command-line flag. Also make two more 'for' loops range-based. NFC llvm-svn: 240680
* Use more range-based for loopsDouglas Katzman2015-06-253-58/+49
| | | | | | Differential Revision: http://reviews.llvm.org/D10738 llvm-svn: 240674
* Teach Clang about the PPC64 memory sanitizer implementation.Jay Foad2015-06-251-1/+4
| | | | | | | | | | | | | | | | Summary: This is the Clang part of the PPC64 memory sanitizer implementation in D10648. Reviewers: kcc, eugenis, willschm, wschmidt, samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10650 llvm-svn: 240628
* Update darwin SDK version parsing to support OSX and simulatorSteven Wu2015-06-251-8/+23
| | | | | | | | | | This re-commits r226005 with a tweak. The origin attempt failed because Darwin bot sets up SDKROOT and clang can deduce SDK version from them after this patch. That broke many driver tests due to the change of deployment target version. Now the tests should not complain after r240574. llvm-svn: 240619
* [UBSan] Allow to use -fsanitize=vptr only on Mac OS 10.9+Alexey Samsonov2015-06-251-5/+5
| | | | | | | See https://llvm.org/bugs/show_bug.cgi?id=23539 for why this is necessary. llvm-svn: 240618
* Express Driver::GetFilePath more concisely.Douglas Katzman2015-06-241-14/+5
| | | | llvm-svn: 240545
* Use range-based loops when handling OPT_print_search_dirs.Douglas Katzman2015-06-231-11/+11
| | | | llvm-svn: 240476
* [Driver] Give GnuTool LLVM_LIBRARY_VISIBILITY.Benjamin Kramer2015-06-231-1/+1
| | | | | | This is consistent with all other classes in Tools.h. llvm-svn: 240464
* Pedantically rename all Tool subclasses to be nouns, not verbs. NFCDouglas Katzman2015-06-236-476/+443
| | | | | | | | | | | | | | | | | | Classes in Tools.h inherit ultimately from Tool, which is a noun, but subclasses of Tool were named for their operation, such as "Compile", wherein the constructor call "Compile(args...)" could be misconstrued as actually causing a compile to happen. Likewise various other methods were not harmonious with their effect, in that "BuildLinker()" returned a "new namespace::Link(...)" instead of a "new namespace::Linker(...)" which it now does. Exceptions: Clang and ClangAs are un-renamed. Those are their rightful names. And there is no particulary great way to name the "Lipo-er" and a few others. Differential Revision: http://reviews.llvm.org/D10595 llvm-svn: 240455
* Driver: Pass -I options to cc1as for .include search paths.Jim Grosbach2015-06-231-0/+3
| | | | llvm-svn: 240432
* Eliminate "enumeration value not handled in switch" warningsDouglas Katzman2015-06-231-0/+2
| | | | | | (Caused by r240370) llvm-svn: 240376
* Change some if/else chains to 'switch' statements. NFCDouglas Katzman2015-06-231-24/+46
| | | | | | Differential Revision: http://reviews.llvm.org/D10612 llvm-svn: 240370
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-222-7/+7
| | | | llvm-svn: 240353
* Update for LLVM API change to return by InputArgList directly (rather than ↵David Blaikie2015-06-221-28/+30
| | | | | | by pointer) from ParseArgs llvm-svn: 240349
* Add comment about the importance of being adjacent. NFCDouglas Katzman2015-06-221-0/+3
| | | | llvm-svn: 240328
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-222-7/+7
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* ArrayRef-ify ParseArgsDavid Blaikie2015-06-211-4/+3
| | | | llvm-svn: 240237
* [Sanitizers] Provide better diagnostic for sanitizers unsupported for target ↵Alexey Samsonov2015-06-195-49/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | triple. Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support and are not toolchain- or architecture-dependent. Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539). Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. This change was first submitted as r239953 and reverted in r239958. The problem was and still is in Darwin toolchains, which get the knowledge about target platform too late after initializaition, while now we require this information when ToolChain::getSanitizerArgs() is called. r240170 works around this issue. llvm-svn: 240179
* [CFI] Require -flto instead of implying it.Alexey Samsonov2015-06-193-18/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is unfortunate, but would let us land http://reviews.llvm.org/D10467, that makes ToolChains responsible for computing the set of sanitizers they support. Unfortunately, Darwin ToolChains doesn't know about actual OS they target until ToolChain::TranslateArgs() is called. In particular, it means we won't be able to construct SanitizerArgs for these ToolChains before that. This change removes SanitizerArgs::needsLTO() method, so that now ToolChain::IsUsingLTO(), which is called very early, doesn't need SanitizerArgs to implement this method. Docs and test cases are updated accordingly. See https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we start all these. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10560 llvm-svn: 240170
* Add nominal support for 'shave' target.Douglas Katzman2015-06-195-0/+171
| | | | | | | | | | | | | | This change passes through C and assembler jobs to Movidius tools by constructing commands which are the same as ones produces by the examples in the SDK. But rather than reference MV_TOOLS_DIR to find tools, we will assume that binaries are installed wherever the Driver would find its native tools. Similarly, this change assumes that -I options will "just work" based on where SDK headers get installed, rather than baking into the Driver some magic paths. Differential Revision: http://reviews.llvm.org/D10440 llvm-svn: 240134
* [ASan] Initial support for Kernel AddressSanitizerAlexander Potapenko2015-06-191-1/+4
| | | | | | | | | This patch adds initial support for the -fsanitize=kernel-address flag to Clang. Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported. Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux. To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used. llvm-svn: 240131
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-191-2/+6
| | | | | | | | | | | | | | | | | This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
* Introduce -fsanitize-trap= flag.Peter Collingbourne2015-06-181-17/+75
| | | | | | | | | | | | | | | | | | | | | | | | This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
* [Driver] Compute MacOS/iOS version from triple if/when we actually need it. NFC.Alexey Samsonov2015-06-182-33/+19
| | | | llvm-svn: 240065
* Allow case-insensitive values for -march for AArch64 target in line with GCC.Gabor Ballabas2015-06-181-1/+2
| | | | | | | GCC allows case-insensitive values for -mcpu, -march and -mtune options. This patch implements the same behaviour for the -march option for the AArch64 target. llvm-svn: 240019
* [Driver] Remove unused class member. NFC.Alexey Samsonov2015-06-182-9/+0
| | | | llvm-svn: 239981
* [Driver] Simplify code choosing between MacOS and iOS platforms. NFC.Alexey Samsonov2015-06-181-12/+10
| | | | llvm-svn: 239980
* [Driver] Add an assert to Darwin::isTargetMacOS() for consistency.Alexey Samsonov2015-06-171-0/+1
| | | | llvm-svn: 239967
* Revert "[Sanitizers] Provide better diagnostic for sanitizers unsupported ↵Alexey Samsonov2015-06-174-84/+45
| | | | | | | | | for target triple." This reverts commit r239953, while I'm investigating assertion failure from http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/9994/ llvm-svn: 239958
* [Sanitizers] Provide better diagnostic for sanitizers unsupported for target ↵Alexey Samsonov2015-06-174-45/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | triple. Summary: Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support (i.e. set from -fsanitize=undefined-trap). Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539) Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith Differential Revision: http://reviews.llvm.org/D10467 llvm-svn: 239953
OpenPOWER on IntegriCloud