summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [Driver] Support for disabling sanitizer runtime linkingPetr Hosek2019-08-042-22/+28
| | | | | | | | | | | This change introduces a pair of -fsanitize-link-runtime and -fno-sanitize-link-runtime flags which can be used to control linking of sanitizer runtimes. This is useful in certain environments like kernels where existing runtime libraries cannot be used. Differential Revision: https://reviews.llvm.org/D65029 llvm-svn: 367794
* The MinGW linker supports response filesReid Kleckner2019-08-021-1/+2
| | | | | | | | | | This affects both LLD and ld.bfd. This isn't testable with a normal driver test with -### because those command lines are printed before response file setup. I tested manually and confirmed it seems to do the right thing. llvm-svn: 367733
* Add support for openSUSE RISC-V tripleSam Elliott2019-08-011-1/+2
| | | | | | | | | | | | | | | | Reviewers: asb Reviewed By: asb Subscribers: lenary, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lebedev.ri, kito-cheng, shiva0217, rogfer01, dexonsmith, rkruppe, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63497 Patch by Andreas Schwab (schwab) llvm-svn: 367565
* [RISCV] Add FreeBSD targetsSam Elliott2019-08-011-0/+8
| | | | | | | | | | | | | | | | Reviewers: asb Reviewed By: asb Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57795 Patch by James Clarke (jrtc27) llvm-svn: 367557
* [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.Puyan Lotfi2019-07-311-4/+11
| | | | | | | | | | | | | Second landing attempt: Changed TY_ObjCXXHeader to TY_PP_ObjCXXHeader to fix -xobjective-c++-header. This time I verified against preprocessor output. Dropping the 'u' entry and the entire Flags table from Types.def. Now it'll be a bit easier to tablegenify this. Differential Revision: https://reviews.llvm.org/D65308 llvm-svn: 367478
* Revert "[NFC][clang] Refactor getCompilationPhases()+Types.def step 3."Sam McCall2019-07-301-11/+4
| | | | | | | This reverts commit d2254dbf21a3243233b75294ef901086199df1b9. This (unintentionally?) changed behavior, disallowing e.g. -x objective-c++-header llvm-svn: 367353
* [Driver] Support -fsanitize=function on Solaris/x86Rainer Orth2019-07-301-0/+3
| | | | | | | | | | | | | | | | UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently FAILs on Solaris/x86_64: clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11' AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only), which is what this patch does, together with updating another testcase. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64488 llvm-svn: 367351
* [NFC] simplify Darwin environment handlingJF Bastien2019-07-301-16/+12
| | | | | | | The previous code detected conflicts through copy-pasta, this versions uses a 'loop'. llvm-svn: 367350
* [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.Puyan Lotfi2019-07-301-4/+11
| | | | | | | | | Dropping the 'u' entry and the entire Flags table from Types.def. Now it'll be a bit easier to tablegenify this. Differential Revision: https://reviews.llvm.org/D65308 llvm-svn: 367345
* [PowerPC] [Clang] Add platform guards to PPC vector intrinsics headersQiu Chaofan2019-07-301-4/+1
| | | | | | | | | | | | Move the platform check out of PPC Linux toolchain code and add platform guards to the intrinsic headers, since they are supported currently only on 64-bit PowerPC targets. Reviewed By: Jinsong Ji Differential Revision: https://reviews.llvm.org/D64849 llvm-svn: 367281
* [Driver] Fix "unannotated fall-through between switch labels". NFCBjorn Pettersson2019-07-271-0/+1
| | | | | | Just a simple fix of Werror problem after r367165. llvm-svn: 367177
* driver: Don't warn about assembler flags being unused when not assembling; ↵Nico Weber2019-07-271-0/+32
| | | | | | | | | | | | | | | | | | | | | different approach This morally relands r365703 (and r365714), originally reviewed at https://reviews.llvm.org/D64527, but with a different implementation. Relanding the same approach with a fix for the revert reason got a bit involved (see https://reviews.llvm.org/D65108) so use a simpler approach with a more localized implementation (that in return duplicates code a bit more). This approach also doesn't validate flags for the integrated assembler if the assembler step doesn't run. Fixes PR42066. Differential Revision: https://reviews.llvm.org/D65233 llvm-svn: 367165
* [NFC][clang] Refactor getCompilationPhases()+Types.def step 2.Puyan Lotfi2019-07-251-38/+18
| | | | | | | | | | | | | | | | | | | | - Removing a few of the entries in the Flags for the Types.def table. - Removing redundant parts of getCompilationPhases(). Flags have been removed from Types.def: a - The type should only be assembled: Now, check that Phases contains phases::Assemble but not phases::Compile or phases::Backend. p - The type should only be precompiled: Now, check that Phases contains phases::Precompile but that Flags does not contain 'm'. m - Precompiling this type produces a module file: Now, check that isPrepeocessedModuleType. Differential Revision: https://reviews.llvm.org/D65176 llvm-svn: 367063
* [Support] Fix `-ftime-trace-granularity` optionAnton Afanasyev2019-07-241-0/+1
| | | | | | | | | | | | | | | | Summary: Move `-ftime-trace-granularity` option to frontend options. Without patch this option is showed up in the help for any tool that links libSupport. Reviewers: sammccall Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65202 llvm-svn: 366911
* [NFC][clang] Refactor getCompilationPhases()+Types.def step 1.Puyan Lotfi2019-07-222-11/+27
| | | | | | | | | | | Moves list of phases into Types.def table: Currently Types.def contains a table of strings that are used to assemble a list of compilation phases to be setup in the clang driver's jobs pipeline. This change makes it so that the table itself contains the list of phases. A subsequent patch will remove the strings. Differential Revision: https://reviews.llvm.org/D64098 llvm-svn: 366761
* [Driver] Set the default win32-macho debug format to DWARFVedant Kumar2019-07-221-3/+5
| | | | | | | | rdar://53267670 Differential Revision: https://reviews.llvm.org/D65116 llvm-svn: 366744
* [Clang] Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer'Yuanfang Chen2019-07-201-13/+23
| | | | | | | | | | | | | | | | with '-mframe-pointer' After D56351 and D64294, frame pointer handling is migrated to tri-state (all, non-leaf, none) in clang driver and on the function attribute. This patch makes the frame pointer handling cc1 option tri-state. Reviewers: chandlerc, rnk, t.p.northover, MaskRay Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D56353 llvm-svn: 366645
* [Driver] Enable __cxa_atexit on SolarisRainer Orth2019-07-171-1/+0
| | | | | | | | | | | | | | | | | | | Starting with Solaris 11.4 (which is now the required minimal version), Solaris does support __cxa_atexit. This patch reflects that. One might consider removing the affected tests altogether instead of inverting them, as is done on other targets. Besides, this lets two ASan tests PASS: AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D64491 llvm-svn: 366305
* Fix a typo in target featuresGeorge Burgess IV2019-07-161-1/+1
| | | | | | | | | There was a slight typo in r364352 that ended up causing our backend to complain on some x86 Android builds. This CL fixes that. Differential Revision: https://reviews.llvm.org/D64781 llvm-svn: 366276
* [Driver] Don't pass --dynamic-linker to ld on SolarisRainer Orth2019-07-161-4/+0
| | | | | | | | | | | | | | | | | I noticed that clang currently passes --dynamic-linker to ld. This has been the case since Solaris 11 support was added initially back in 2012 by David Chisnall (r150580). I couldn't find any patch submission, let alone a justification, for this, and it seems completely useless: --dynamic-linker is a gld compatibility form of the option, the native option being -I. First of all, however, the dynamic linker passed is simply the default, so there's no reason at all to specify it in the first place. This patch removes passing the option and adjusts the affected testcase accordingly. Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D64493 llvm-svn: 366202
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-161-1/+2
| | | | | | | | | | | | | | | | | | | | | i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b: * Bump the function_type_mismatch handler version, as its signature has changed. * The function_type_mismatch handler can return successfully now, so SanitizerKind::Function must be AlwaysRecoverable (like for SanitizerKind::Vptr). * But the minimal runtime would still unconditionally treat a call to the function_type_mismatch handler as failure, so disallow -fsanitize=function in combination with -fsanitize-minimal-runtime (like it was already done for -fsanitize=vptr). * Add tests. Differential Revision: https://reviews.llvm.org/D61479 llvm-svn: 366186
OpenPOWER on IntegriCloud