summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Take into account -mcpu and -mfpu options while handling 'crypto' featureDiogo N. Sampaio2019-09-111-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Submittin in behalf of krisb (Kristina Bessonova) <ch.bessonova@gmail.com> Summary: '+crypto' means '+aes' and '+sha2' for arch >= ARMv8 when they were not disabled explicitly. But this is correctly handled only in case of '-march' option, though the feature may also be specified through the '-mcpu' or '-mfpu' options. In the following example: $ clang -mcpu=cortex-a57 -mfpu=crypto-neon-fp-armv8 'aes' and 'sha2' are disabled that is quite unexpected: $ clang -cc1 -triple armv8--- -target-cpu cortex-a57 <...> -target-feature -sha2 -target-feature -aes -target-feature +crypto This exposed by https://reviews.llvm.org/D63936 that makes the 'aes' and 'sha2' features disabled by default. So, while handling the 'crypto' feature we need to take into account: - a CPU name, as it provides the information about architecture (if no '-march' option specified), - features, specified by the '-mcpu' and '-mfpu' options. Reviewers: SjoerdMeijer, ostannard, labrinea, dnsampaio Reviewed By: dnsampaio Subscribers: ikudrin, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66018 Author: krisb llvm-svn: 371597
* Don't emit .gnu_pubnames when tuning for LLDB.Adrian Prantl2019-09-101-1/+0
| | | | | | | | | | | | | | | | LLDB reads the various .apple* accelerator tables (and in the near future: the DWARF 5 accelerator tables) which should make .gnu_pubnames redundant. This changes the Clang driver to no longer pass -ggnu-pubnames when tuning for LLDB. Thanks to David Blaikie for pointing this out! http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190422/thread.html#646062 rdar://problem/50142073 Differential Revision: https://reviews.llvm.org/D67373 llvm-svn: 371530
* [RISCV] Make -march=rv{32,64}gc the default in RISC-V LinuxRoger Ferrer Ibanez2019-09-103-9/+15
| | | | | | | | This is the logical follow-up of D65634. Differential Revision: https://reviews.llvm.org/D66003 llvm-svn: 371496
* [RISCV] Default to ilp32d/lp64d in RISC-V LinuxRoger Ferrer Ibanez2019-09-101-3/+5
| | | | | | | | | | When running clang as a native compiler in RISC-V Linux the flag -mabi=ilp32d / -mabi=lp64d is always mandatory. This change makes it the default there. Differential Revision: https://reviews.llvm.org/D65634 llvm-svn: 371494
* [RISCV] Move architecture parsing code into its own functionRoger Ferrer Ibanez2019-09-101-140/+150
| | | | | | | | | | | I plan to reuse it in a later patch. This is almost NFC except a small change in control flow when diagnosing +d without +f. Differential Revision: https://reviews.llvm.org/D66002 llvm-svn: 371492
* [Driver] Handle default case in refactored addOpenMPRuntimePirama Arumuga Nainar2019-09-091-0/+2
| | | | | | | | | | | | | | | | | | | Summary: Appease failed builds (due to -Werror and -Wswitch) where OMPRT_Unknown is not handled in the switch statement (even though it's handled by the early exit). This fixes -Wswitch triggered by r371442. Reviewers: srhines, danalbert, jdoerfert Subscribers: guansong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67364 llvm-svn: 371444
* [Driver] Add -static-openmp driver optionPirama Arumuga Nainar2019-09-095-12/+34
| | | | | | | | | | | | | | | | | | | | | | Summary: For Gnu, FreeBSD and NetBSD, this option forces linking with the static OpenMP host runtime (similar to -static-libgcc and -static-libstdcxx). Android's NDK will start the shared OpenMP runtime in addition to the static libomp. In this scenario, the linker will prefer to use the shared library by default. Add this option to enable linking with the static libomp. Reviewers: Hahnfeld, danalbert, srhines, joerg, jdoerfert Subscribers: guansong, cfe-commits Tags: #clang Fixes https://github.com/android-ndk/ndk/issues/1028 Differential Revision: https://reviews.llvm.org/D67200 llvm-svn: 371437
* Revert r361885 "[Driver] Fix -working-directory issues"Hans Wennborg2019-09-052-25/+34
| | | | | | | | | | | | | | | | | | | | | | | This made clang unable to open files using relative paths on network shares on Windows (PR43204). On the bug it was pointed out that createPhysicalFileSystem() is not terribly mature, and using it is risky. Reverting for now until there's a clear way forward. > Currently the `-working-directory` option does not actually impact the working > directory for all of the clang driver, it only impacts how files are looked up > to make sure they exist. This means that that clang passes the wrong paths > to -fdebug-compilation-dir and -coverage-notes-file. > > This patch fixes that by changing all the places in the driver where we convert > to absolute paths to use the VFS, and then calling setCurrentWorkingDirectory on > the VFS. This also changes the default VFS for `Driver` to use a virtualized > working directory, instead of changing the process's working directory. > > Differential Revision: https://reviews.llvm.org/D62271 This also revertes the part of r369938 which checked that -working-directory works. llvm-svn: 371027
* [Driver] Use shared singleton instance of DriverOptTableIlya Biryukov2019-09-042-35/+40
| | | | | | | | | | | | | | | | | | | | | Summary: This significantly reduces the time required to run clangd tests, by ~10%. Should also have an effect on other tests that run command-line parsing multiple times inside a single invocation. Reviewers: gribozavr, sammccall Reviewed By: sammccall Subscribers: kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67163 llvm-svn: 370908
* Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"Roman Lebedev2019-09-041-6/+0
| | | | | | | | | Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency graphs. (clangInterp depends on clangAST which depends on clangInterp) This reverts r370839, which is an yet another recommit of D64146. llvm-svn: 370874
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-041-0/+6
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370839
* clang: default to DWARF 4 for FreeBSD 12.0 and laterEd Maste2019-09-032-1/+7
| | | | | | | | | | | | Older FreeBSD versions included GDB 6.1 and had other tools that were unable to handle debug information newer than DWARF 2. Those tools have since been updated. (An old version of GDB is still kept for kernel crash handling, but the kernel is compiled with an explicit -gdwarf2.) Reviewed by: dim Differential Revision: https://reviews.llvm.org/D66760 llvm-svn: 370779
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-021-6/+0
| | | | | | This reverts r370636 (git commit 8327fed9475a14c3376b4860c75370c730e08f33) llvm-svn: 370642
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-021-0/+6
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370636
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-311-6/+0
| | | | | | This reverts r370584 (git commit afcb3de117265a69d21e5673356e925a454d7d02) llvm-svn: 370588
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-311-0/+6
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370584
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-6/+0
| | | | | | This reverts r370531 (git commit d4c1002e0bbbbab50f6891cdd2f5bd3a8f3a3584) llvm-svn: 370535
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-0/+6
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370531
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-6/+0
| | | | | | This reverts r370476 (git commit a5590950549719d0d9ea69ed164b0c8c0f4e02e6) llvm-svn: 370481
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-0/+6
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370476
* [driver][xray] fix the macOS support checker by supporting -macosAlex Lorenz2019-08-271-1/+1
| | | | | | | | | | | triple in addition to -darwin The previous check incorrectly checked for macOS support by allowing -darwin triples only, and -macos triple was not supported. Differential Revision: https://reviews.llvm.org/D61758 llvm-svn: 370093
* [driver] add a new option `-gen-cdb-fragment-path` to emitAlex Lorenz2019-08-262-4/+50
| | | | | | | | | | | | | | a fragment of a compilation database for each compilation This patch adds a new option called -gen-cdb-fragment-path to the driver, which can be used to specify a directory path to which clang can emit a fragment of a CDB for each compilation it needs to invoke. This option emits the same CDB contents as -MJ, and will be ignored if -MJ is specified. Differential Revision: https://reviews.llvm.org/D66555 llvm-svn: 369938
* Fix -dA flag, it is not a preprocessor flag.Erich Keane2019-08-261-2/+1
| | | | | | | | | -dA was in the d_group, which is a preprocessor state dumping group. However -dA is a debug flag to cause a verbose asm. It was already implemented to do the same thing as -fverbose-asm, so make it just be an alias. llvm-svn: 369926
* [clang][ifs] Dropping older experimental interface stub formats.Puyan Lotfi2019-08-221-11/+16
| | | | | | | | | | | | I've been working on a new tool, llvm-ifs, for merging interface stub files generated by clang and I've iterated on my derivative format of TBE to a newer format. llvm-ifs will only support the new format, so I am going to drop the older experimental interface stubs formats in this commit to make things simpler. Differential Revision: https://reviews.llvm.org/D66573 llvm-svn: 369719
* [clang][ifs] New interface stubs format (llvm triple based).Puyan Lotfi2019-08-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | After posting llvm-ifs on phabricator, I made some progress in hardening up how I think the format for Interface Stubs should look. There are a number of things I think the TBE format was missing (no endianness, no info about the Object Format because it assumes ELF), so I have added those and broken off from being as similar to the TBE schema. In a subsequent commit I can drop the other formats. An example of how The format will look is as follows: --- !experimental-ifs-v1 IfsVersion: 1.0 Triple: x86_64-unknown-linux-gnu ObjectFileFormat: ELF Symbols: _Z9nothiddenv: { Type: Func } _Z10cmdVisiblev: { Type: Func } ... The format is still marked experimental. Differential Revision: https://reviews.llvm.org/D66446 llvm-svn: 369715
* Revert r369402 "win: Enable /Zc:twoPhase by default if targeting MSVC 2017 ↵Hans Wennborg2019-08-221-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | update 3 or newer" This broke compiling some ASan tests with never versions of MSVC/the Win SDK, see https://crbug.com/996675 > MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and > so should clang-cl: > https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase > > clang-cl takes the MSVC version it emulates from the -fmsc-version flag, > or if that's not passed it tries to check what the installed version of > MSVC is and uses that, and failing that it uses a default version that's > currently 1911. So this changes the default if no -fmsc-version flag is > passed and no installed MSVC is detected. (It also changes the default > if -fmsc-version is passed or MSVC is detected, and either indicates > _MSC_VER >= 1911.) > > As mentioned in the MSDN article, the Windows SDK header files in > version 10.0.15063.0 (Creators Update or Redstone 2) and earlier > versions do not work correctly with /Zc:twoPhase. If you need to use > these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get > the old behavior. > > Fixes PR43032. > > Differential Revision: https://reviews.llvm.org/D66394 llvm-svn: 369647
* win: Enable /Zc:twoPhase by default if targeting MSVC 2017 update 3 or newerNico Weber2019-08-201-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and so should clang-cl: https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase clang-cl takes the MSVC version it emulates from the -fmsc-version flag, or if that's not passed it tries to check what the installed version of MSVC is and uses that, and failing that it uses a default version that's currently 1911. So this changes the default if no -fmsc-version flag is passed and no installed MSVC is detected. (It also changes the default if -fmsc-version is passed or MSVC is detected, and either indicates _MSC_VER >= 1911.) As mentioned in the MSDN article, the Windows SDK header files in version 10.0.15063.0 (Creators Update or Redstone 2) and earlier versions do not work correctly with /Zc:twoPhase. If you need to use these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get the old behavior. Fixes PR43032. Differential Revision: https://reviews.llvm.org/D66394 llvm-svn: 369402
* [X86] Support -mlong-double-80Troy A. Johnson2019-08-171-4/+5
| | | | | | | | | | | | | Add an option group for all of the -mlong-double-* options and make -mlong-double-80 restore the default long double behavior for X86. The motivations are that GNU accepts the -mlong-double-80 option and that complex Makefiles often need a way of undoing earlier options. Prior to this commit, if one chooses 64-bit or 128-bit long double for X86, there is no way to undo that choice and restore the 80-bit behavior. Differential Revision: https://reviews.llvm.org/D66055 llvm-svn: 369183
* Revert "[X86] Support -mlong-double-80"Troy A. Johnson2019-08-161-6/+4
| | | | | | | This reverts commit 250aafa2c4a1bc2395edfe8d4365545bbe56fffe. Caused buildbot failures -- still investigating. llvm-svn: 369170
* [X86] Support -mlong-double-80Troy A. Johnson2019-08-161-4/+6
| | | | | | | | | | | | | Add an option group for all of the -mlong-double-* options and make -mlong-double-80 restore the default long double behavior for X86. The motivations are that GNU accepts the -mlong-double-80 option and that complex Makefiles often need a way of undoing earlier options. Prior to this commit, if one chooses 64-bit or 128-bit long double for X86, there is no way to undo that choice and restore the 80-bit behavior. Differential Revision: https://reviews.llvm.org/D66055 llvm-svn: 369152
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1431-115/+115
| | | | | | | | | | 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
* [NFC][clang] Moving argument handling: Driver::BuildActions -> handleArgumentsPuyan Lotfi2019-08-141-114/+118
| | | | | | | | | | This patch simply moves code that already exists into a new function. Specifically I think it will make the BuildActions code for building a clang job pipeline easier to read and work with. Differential Revision: https://reviews.llvm.org/D66058 llvm-svn: 368881
* Fix _WIN32 / _WIN64 Wundef warningsSven van Haastregt2019-08-141-1/+1
| | | | | | | | For these macros it is the definedness that matters rather than the value. Make new uses of these macros consistent with existing uses. llvm-svn: 368822
* [NFC][clang] Adding argument based Phase list filtering to getComplicationPhasesPuyan Lotfi2019-08-132-10/+62
| | | | | | | | | | This patch removes usage of FinalPhase from anywhere outside of the scope where it is used to do argument handling. It also adds argument based trimming of the Phase list pulled out of the Types.def table. Differential Revision: https://reviews.llvm.org/D65993 llvm-svn: 368734
* clang: Don't warn on unused momit-leaf-frame-pointer when frame pointers are ↵Nico Weber2019-08-131-3/+14
| | | | | | | | | | | | | | | | | | | | off. This fixes a regression from r365860: As that commit message states, there are 3 valid states targeted by the combination of -f(no-)omit-frame-pointer and -m(no-)omit-leaf-frame-pointer. After r365860 it's impossible to get from state 10 (omit just leaf frame pointers) to state 11 (omit all frame pointers) in a single command line without getting a warning. This change restores that functionality. Fixes PR42966. Differential Revision: https://reviews.llvm.org/D66142 llvm-svn: 368728
* Enable memtag sanitizer in all AArch64 toolchainsMomchil Velikov2019-08-132-2/+3
| | | | | | | | That sanitizer does not have runtime library or other dependencies. Differential Revision: https://reviews.llvm.org/D65642 llvm-svn: 368697
* [AArch64] Make the memtag sanitizer require the memtag extensionMomchil Velikov2019-08-131-0/+15
| | | | | | | | ... or otherwise we get an ICE. Differential Revision: https://reviews.llvm.org/D65508 llvm-svn: 368696
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
* [clang][NFC] Consolidating usage of "FinalPhase" in Driver::BuildActions.Puyan Lotfi2019-08-091-83/+100
| | | | | | | | | | | | | | I am working to remove this concept of the "FinalPhase" in the clang driver, but it is used in a lot of different places to do argument handling for different combinations of phase pipelines and arguments. I am trying to consolidate most of the uses of "FinalPhase" into its own separate scope. Eventually, in a subsequent patch I will move all of this stuff to a separate function, and have more of the complication phase list construction setup into types::getComplicationPhases. Differential Revision: https://reviews.llvm.org/D65969 llvm-svn: 368393
* [clang] Add no-warn support for WaBrian Cain2019-08-081-0/+2
| | | | llvm-svn: 368328
* [Driver] Move LIBRARY_PATH before user inputsFangrui Song2019-08-081-6/+5
| | | | | | | | | | | | | | | | Fixes PR16786 Currently, library paths specified by LIBRARY_PATH are placed after inputs: `inputs LIBRARY_PATH stdlib` In gcc, the order is: `LIBRARY_PATH inputs stdlib` if not cross compiling. (On Darwin targets, isCrossCompiling() always returns false.) This patch changes the behavior to match gcc. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D65880 llvm-svn: 368245
* [RISCV] Remove duplicated logic when determining the target ABIRoger Ferrer Ibanez2019-08-072-13/+9
| | | | | | | | We were calculating twice ilp32/lp64. Do this in one place instead. Differential Revision: https://reviews.llvm.org/D48357 llvm-svn: 368128
* hwasan: Instrument globals.Peter Collingbourne2019-08-061-0/+5
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* [Driver] Introduce -stdlib++-isystemShoaib Meenai2019-08-062-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
* [Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-muslFangrui Song2019-08-061-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a musl-based Linux distribution, stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h are expected to be provided by musl (/usr/include), instead of RESOURCE_DIR/include. Reorder RESOURCE_DIR/include to fix the search order problem. (Currently musl doesn't provide stdatomic.h. stdatomic.h is still found in RESOURCE_DIR/include.) gcc on musl has a similar search order: ``` /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-alpine-linux-musl /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward /usr/local/include /usr/include/fortify /usr/include /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/include ``` This is different from a glibc-based distribution where RESOURCE_DIR/include is placed before SYSROOT/usr/include. According to the maintainer of musl: > musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident. Reviewed by: phosek Differential Revision: https://reviews.llvm.org/D65699 llvm-svn: 367981
* [Driver] Properly use values-X[ca].o, values-xpg[46].o on SolarisRainer Orth2019-08-051-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and x86, 32 and 64-bit. It turned out that this is due to different behaviour of logb depending on the C standard compiled for, as documented on logb(3M): RETURN VALUES Upon successful completion, these functions return the exponent of x. If x is subnormal: o For SUSv3-conforming applications compiled with the c99 com- piler driver (see standards(7)), the exponent of x as if x were normalized is returned. o Otherwise, if compiled with the cc compiler driver, -1022, -126, and -16382 are returned for logb(), logbf(), and logbl(), respectively. Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those. The following patch fixes this by following what gcc does, as corrected some time ago in Fix use of Solaris values-Xc.o (PR target/40411) https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html. Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D64793 llvm-svn: 367866
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-053-4/+5
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [Driver] Don't disable -fsanitizer-coverage for safe-stack or shadow-call-stackPetr Hosek2019-08-051-1/+2
| | | | | | | | | These "sanitizers" are hardened ABIs that are wholly orthogonal to the SanitizerCoverage instrumentation. Differential Revision: https://reviews.llvm.org/D65715 llvm-svn: 367799
* [Driver] Derive Fuchsia Linker directly from ToolPetr Hosek2019-08-051-2/+2
| | | | | | Fuchsia Linker tool doesn't need any of the GnuTool behavior. llvm-svn: 367797
* [Driver] Always use -z separate-code with lld on FuchsiaPetr Hosek2019-08-051-0/+2
| | | | | | | Previously -z separate-code was the default lld behavior, but now it has to be explicitly requested by specifying the flag. llvm-svn: 367796
OpenPOWER on IntegriCloud