summaryrefslogtreecommitdiffstats
path: root/clang/test/Driver
Commit message (Collapse)AuthorAgeFilesLines
...
* Add -m(no)-spe to clangJustin Hibbits2019-09-051-0/+3
| | | | | | | | | | | | | | Summary: r337347 added support for the Signal Processing Engine (SPE) to LLVM. This follows that up with the clang side. This adds -mspe and -mno-spe, to match GCC. Subscribers: nemanjai, kbarton, cfe-commits Differential Revision: https://reviews.llvm.org/D49754 llvm-svn: 371066
* Revert r361885 "[Driver] Fix -working-directory issues"Hans Wennborg2019-09-052-17/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid assemble step in verbose-output-quoting.cYuanfang Chen2019-09-041-8/+8
| | | | | | | | | | | | Reviewers: hans Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65527 llvm-svn: 370928
* clang: default to DWARF 4 for FreeBSD 12.0 and laterEd Maste2019-09-031-2/+6
| | | | | | | | | | | | 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
* [X86] Remove what little support we had for MPXCraig Topper2019-08-291-2/+2
| | | | | | | | | | | | | | | -Deprecate -mmpx and -mno-mpx command line options -Remove CPUID detection of mpx for -march=native -Remove MPX from all CPUs -Remove MPX preprocessor define I've left the "mpx" string in the backend so we don't fail on old IR, but its not connected to anything. gcc has also deprecated these command line options. https://www.phoronix.com/scan.php?page=news_item&px=GCC-Patch-To-Drop-MPX Differential Revision: https://reviews.llvm.org/D66669 llvm-svn: 370393
* [Test][Time profiler] Fix test for python3Anton Afanasyev2019-08-291-3/+3
| | | | | | | | | | | | | | | | Summary: Fix test checking time profiler generates correct tracing json-file. `filter` works differently for python2 and python3, so unifying this. Reviewers: mgehre, nathanchance Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66873 llvm-svn: 370300
* [Clang][Bundler] Do not require host triple for extracting device bundlesSergey Dmitriev2019-08-281-0/+20
| | | | | | | | Bundler currently requires host triple to be provided no matter if you are performing bundling or unbundling, but for unbundling operation such requirement is too restrictive. You may for example want to examine device part of the object for a particular offload target, but you have to extract host part as well even though you do not need it. Host triple isn't really needed for unbundling, so this patch removes that requirement. Differential Revision: https://reviews.llvm.org/D66601 llvm-svn: 370143
* [Clang][Bundler] Fix for a hang when unbundling fat binarySergey Dmitriev2019-08-271-0/+5
| | | | | | | | clang-offload-bundler tool may hang under certain conditions when it extracts a subset of all available device bundles from the fat binary that is handled by the BinaryFileHandler. This patch fixes this problem. Differential Revision: https://reviews.llvm.org/D66598 llvm-svn: 370115
* [driver][xray] fix the macOS support checker by supporting -macosAlex Lorenz2019-08-271-0/+4
| | | | | | | | | | | 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
* [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 ↵Sam Elliott2019-08-272-0/+178
| | | | | | | | | | | | | | | | | | targets with atomics Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called. Reviewers: jfb, jyknight, wmi, asb Reviewed By: asb Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57450 llvm-svn: 370073
* Fix gen-cdb-fragment test for WindowsAlex Lorenz2019-08-261-2/+2
| | | | | | Windows bots didn't seem to like the empty argument, so I rewrote the test. llvm-svn: 369956
* [Clang][Bundler] Use llvm-objcopy for creating fat object filesSergey Dmitriev2019-08-261-6/+3
| | | | | | | | clang-offload-bundler currently uses partial linking for creating fat object files, but such technique cannot be used on Windows due to the absence of partial linking support in the linker. This patch changes implementation to use llvm-objcopy for merging device and host objects instead of doing partial linking. This is one step forward towards enabling OpenMP offload on Windows. Differential Revision: https://reviews.llvm.org/D66485 llvm-svn: 369955
* [driver] add a new option `-gen-cdb-fragment-path` to emitAlex Lorenz2019-08-261-0/+37
| | | | | | | | | | | | | | 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
* [OpenCL] Renamed value of std flag in C++ mode.Anastasia Stulova2019-08-231-1/+1
| | | | | | | | Clang should accept -std=clc++ (not -std=c++!) for OpenCL. This was forgotten in r367008. llvm-svn: 369779
* Revert r369402 "win: Enable /Zc:twoPhase by default if targeting MSVC 2017 ↵Hans Wennborg2019-08-221-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Support][Time profiler] Make FE codegen blocks to be inside frontend blocksAnton Afanasyev2019-08-192-0/+32
| | | | | | | | | | | | | | | | | | | | | | Summary: Add `Frontend` time trace entry to `HandleTranslationUnit()` function. Add test to check all codegen blocks are inside frontend blocks. Also, change `--time-trace-granularity` option a bit to make sure very small time blocks are outputed to json-file when using `--time-trace-granularity=0`. This fixes http://llvm.org/pr41969 Reviewers: russell.gallop, lebedev.ri, thakis Reviewed By: russell.gallop Subscribers: vsapsai, aras-p, lebedev.ri, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63325 llvm-svn: 369308
* [X86] Support -mlong-double-80Troy A. Johnson2019-08-171-1/+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-5/+1
| | | | | | | This reverts commit 250aafa2c4a1bc2395edfe8d4365545bbe56fffe. Caused buildbot failures -- still investigating. llvm-svn: 369170
* [X86] Support -mlong-double-80Troy A. Johnson2019-08-161-1/+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: 369152
* Mark the test as unsupported on darwin, NFC.Alexey Bataev2019-08-151-1/+1
| | | | | | The bundler may fail on darwin, mark the test as not compatible. llvm-svn: 369044
* Fix the test, NFC.Alexey Bataev2019-08-151-1/+1
| | | | llvm-svn: 369028
* [Driver][Bundler] Improve bundling of object files.Alexey Bataev2019-08-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, object files were bundled using partial linking. It resulted in the following structure of the bundled objects: ``` <host_code> clang-offload-bundle __CLANG_OFFLOAD_BUNDLE__<target> <target_code> ``` But when we tried to unbundle object files, it worked correctly only for the target objects. The host object remains bundled. It produced a lot of junk sections in the host object files and in some cases may caused incorrect linking. Patch improves bundling of the object files. After this patch the bundled object looks like this: ``` <host_code> clang-offload-bundle __CLANG_OFFLOAD_BUNDLE__<target> <target_code> __CLANG_OFFLOAD_BUNDLE__<host> <host_code> ``` With this structure we are able to unbundle the host object files too so that after unbundling they are the same as were before. The host section is bundled twice. The bundled section is used to unbundle the original host section. Reviewers: yaxunl, tra, jlebar, hfinkel, jdoerfert Subscribers: caomhin, kkwli0, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65819 llvm-svn: 369019
* [BUNDLER]Improve the test, NFC.Alexey Bataev2019-08-152-57/+60
| | | | | | | | | | | | | | | | Summary: Make the test more portable and do not rely on the pre-bundled object file. Reviewers: Hahnfeld, hfinkel, jdoerfert Subscribers: caomhin, kkwli0, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66296 llvm-svn: 369015
* [AMDGPU] Do not assume a default GCN targetStanislav Mekhanoshin2019-08-141-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D66246 llvm-svn: 368917
* clang: Don't warn on unused momit-leaf-frame-pointer when frame pointers are ↵Nico Weber2019-08-131-0/+10
| | | | | | | | | | | | | | | | | | | | 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
* [AArch64] Make the memtag sanitizer require the memtag extensionMomchil Velikov2019-08-131-0/+10
| | | | | | | | ... or otherwise we get an ICE. Differential Revision: https://reviews.llvm.org/D65508 llvm-svn: 368696
* [X86] Support -march=tigerlakePengfei Wang2019-08-121-0/+4
| | | | | | | | | | | | Support -march=tigerlake for x86. Compare with Icelake Client, It include 4 more new features ,they are avx512vp2intersect, movdiri, movdir64b, shstk. Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D65840 llvm-svn: 368543
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update test to explicity test with -fintegrated-as and -fno-integrated-as ↵Douglas Yung2019-08-091-7/+39
| | | | | | | | | | and to expect warnings when appropriate. Reviewed by: thakis Differential Revision: https://reviews.llvm.org/D65974 llvm-svn: 368474
* [clang] add REQUIRES: linux to driver test caseBrian Cain2019-08-081-0/+1
| | | | | | | The test case explicitly leverages linux, so should include it as a test requirement. llvm-svn: 368334
* [clang] add REQUIRES to driver test caseBrian Cain2019-08-081-0/+3
| | | | | | | The test case explicitly leverages x86, so should include it as a test requirement. llvm-svn: 368332
* [clang] Add no-warn support for WaBrian Cain2019-08-081-0/+14
| | | | llvm-svn: 368328
* [Driver] Delete XFAIL: windows-msvc after D65880/r368245Fangrui Song2019-08-081-1/+0
| | | | | | `-target %itanium_abi_triple` fixed the problem. llvm-svn: 368251
* [Driver] Move LIBRARY_PATH before user inputsFangrui Song2019-08-081-3/+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
* hwasan: Instrument globals.Peter Collingbourne2019-08-061-0/+2
| | | | | | | | | | | | | | | | | | 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-061-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0510-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Driver] Don't disable -fsanitizer-coverage for safe-stack or shadow-call-stackPetr Hosek2019-08-051-1/+13
| | | | | | | | | These "sanitizers" are hardened ABIs that are wholly orthogonal to the SanitizerCoverage instrumentation. Differential Revision: https://reviews.llvm.org/D65715 llvm-svn: 367799
* [Driver] Always use -z separate-code with lld on FuchsiaPetr Hosek2019-08-051-1/+1
| | | | | | | 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-041-0/+40
| | | | | | | | | | | 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
* [Driver][test] Avoid undefined grep in darwin-ld.cHubert Tong2019-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: question-mark is not a BRE special character. POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\?` as used by rC366282 is undefined. This patch uses an ERE instead. Reviewers: rnk, daltenty, xingxue, jasonliu Reviewed By: rnk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65668 llvm-svn: 367709
* Test linux only for absolute paths in the -fuse-ld optionYuanfang Chen2019-08-011-0/+1
| | | | | | | Some target do not use this option and may emit a error message for using it. llvm-svn: 367602
* Add support for openSUSE RISC-V tripleSam Elliott2019-08-016-0/+20
| | | | | | | | | | | | | | | | 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/+9
| | | | | | | | | | | | | | | | 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
* [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
* [driver][test] Use /dev/null in as-options.s insteadJordan Rupprecht2019-07-291-3/+3
| | | | llvm-svn: 367256
* [driver][test] Update as-options.s to not write to a readonly treeJordan Rupprecht2019-07-291-2/+3
| | | | | | The as-options.s test writes to the build tree as of r367165. Some build systems configure this to be readonly, so this fails. Explicitly write to the output tree using `%t` to avoid this. llvm-svn: 367253
* [Driver] Additional fixup of NOWARN test case from r367165Bjorn Pettersson2019-07-271-1/+1
| | | | | | | | | | | | Same kind of fix as in r367176, but for "RUN on line 76" this time. I'll ask for a post-commit review, to ensure this matches the intention with the test added in r367165. But I think this at least will make the buildbots a little bit happier. llvm-svn: 367182
OpenPOWER on IntegriCloud