summaryrefslogtreecommitdiffstats
path: root/clang/test/Driver
Commit message (Collapse)AuthorAgeFilesLines
* [RISCV] Fix sysroot tests without GCC on RISC-V hosts with GCCLuís Marques2020-06-252-0/+2
| | | | | | | | | | | | | D68391 added tests that check scenarios where no RISC-V GCC toolchain is supposed to be detected. When running the tests on RISC-V hosts the system's GCC toolchain will be detected, and the tests will fail. This patch adds a `--gcc-toolchain` option pointing to a path where no GCC toolchain is present, ensuring that the tests are run under the expected conditions, and therefore are able to pass in all test environments. Differential Revision: https://reviews.llvm.org/D75061 (cherry picked from commit 91f7f0d8e3ef2b6be07bc9621de075ff11c730c9)
* [X86] Add a Pass that builds a Condensed CFG for Load Value Injection (LVI) ↵Scott Constable2020-06-241-0/+12
| | | | | | | | | | | | | | Gadgets Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph. More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK). Also adds a new target feature to X86: +lvi-load-hardening The feature can be added via the clang CLI using -mlvi-hardening. Differential Revision: https://reviews.llvm.org/D75936
* [X86] Add tests to clang Driver to ensure that SLH/Retpoline features are ↵Scott Constable2020-06-241-0/+7
| | | | | | not enabled with LVI-CFI Differential Revision: https://reviews.llvm.org/D77427
* Revert "[X86] Add a Pass that builds a Condensed CFG for Load Value ↵Craig Topper2020-06-241-5/+0
| | | | | | | | | Injection (LVI) Gadgets" This reverts commit c74dd640fd740c6928f66a39c7c15a014af3f66f. Reverting to address coding standard issues raised in post-commit review.
* [X86] Add a Pass that builds a Condensed CFG for Load Value Injection (LVI) ↵Scott Constable2020-06-241-0/+5
| | | | | | | | | | | | | | Gadgets Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph. More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK). Also adds a new target feature to X86: +lvi-load-hardening The feature can be added via the clang CLI using -mlvi-hardening. Differential Revision: https://reviews.llvm.org/D75936
* [X86] Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI)Scott Constable2020-06-241-0/+5
| | | | | | | | | | | | | | | | | This pass replaces each indirect call/jump with a direct call to a thunk that looks like: lfence jmpq *%r11 This ensures that if the value in register %r11 was loaded from memory, then the value in %r11 is (architecturally) correct prior to the jump. Also adds a new target feature to X86: +lvi-cfi ("cfi" meaning control-flow integrity) The feature can be added via clang CLI using -mlvi-cfi. This is an alternate implementation to https://reviews.llvm.org/D75934 That merges the thunk insertion functionality with the existing X86 retpoline code. Differential Revision: https://reviews.llvm.org/D76812
* [Driver] Support -fsanitize=shadow-call-stack and cfi-icall on aarch64_beFangrui Song2020-06-241-2/+3
| | | | | | | D80647 did not fix https://bugs.llvm.org/show_bug.cgi?id=46076 This is the fix. (cherry picked from commit b9c6871a9570975827dc0bbeb39131c99c8daf8e)
* [Driver] Support -fsanitize=shadow-call-stack on aarch64_beFangrui Song2020-06-241-0/+4
| | | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=46076 Reviewed By: nickdesaulniers, pcc Differential Revision: https://reviews.llvm.org/D80647 (cherry picked from commit a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69)
* [AARch64] Add Marvell ThunderX3T110 supportWei Zhao2020-06-171-0/+28
| | | | | | | | | | | This is the first checkin to support Marvell ThunderX3T110. Initial definition of the micro-ops of the instructions in ThunderX3T110 is included. Differential Revision: https://reviews.llvm.org/D78129 (cherry picked from commit 382d3a85e2a9269569e7fb8caa487d7ef57900c6)
* [CUDA] Warn about unsupported CUDA SDK version only if it's used.Artem Belevich2020-03-231-0/+5
| | | | | | | | | This fixes an issue with clang issuing a warning about unknown CUDA SDK if it's detected during non-CUDA compilation. Differential Revision: https://reviews.llvm.org/D76030 (cherry picked from commit eb2ba2ea953b5ea73cdbb598f77470bde1c6a011)
* [driver][darwin] Don't use -platform_version flag by default (PR44813)Hans Wennborg2020-02-274-9/+27
| | | | | | | | | | | | | | | | | The code in llvmorg-10-init-12188-g25ce33a6e4f is a breaking change for users of older linkers who don't pass a version parameter, which prevents a drop-in clang upgrade. Old tools can't know about what future tools will do, so as a general principle the burden should be new tools to be compatible by default. Also, for comparison, none of the other tests of Version within AddLinkArgs add any new behaviors unless the version is explicitly specified. Therefore, this patch changes the -platform_version behavior from opt-out to opt-in. Patch by David Major! Differential revision: https://reviews.llvm.org/D74784 (cherry picked from commit 5122e828701c88f8d53ee881bc68f3904454d154)
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-191-2/+2
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* [Clang] Limit -fintegrated-cc1 to only one TUAlexandre Ganea2020-02-131-8/+23
| | | | | | | | | | As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode). I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term. Differential Revision: https://reviews.llvm.org/D74490 (cherry picked from commit 20f1abe306d030e99f56185a3aa077ffadf59b8a)
* [Clang][Driver] After default -fintegrated-cc1, make ↵Alexandre Ganea2020-02-121-0/+8
| | | | | | | | | | | | | llvm::report_fatal_error() generate preprocessed source + reproducer.sh again. Added a test for #pragma clang __debug llvm_fatal_error to test for the original issue. Added llvm::sys::Process::Exit() and replaced ::exit() in places where it was appropriate. This new function would call the current CrashRecoveryContext if one is running on the same thread; or call ::exit() otherwise. Fixes PR44705. Differential Revision: https://reviews.llvm.org/D73742 (cherry picked from commit faace365088a2a3a4cb1050a9facfc34a7a56577)
* Re-land "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid ↵Alexandre Ganea2020-02-102-5/+78
| | | | | | | | | | | crashing when generating crash diagnostics when '#pragma clang __debug ..." This re-lands commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af (https://reviews.llvm.org/D74076) and commit 5fedc2b410853a6aef05e8edf19ebfc4e071e28f (https://reviews.llvm.org/D74070) The previous build break was caused by '#pragma clang __debug llvm_unreachable' used in a non-assert build. Move it to a separate test in crash-report-with-asserts.c. (cherry picked from commit 75f09b54429bee17a96e2ba7a2ac0f0a8a7f7e74)
* [CUDA] Assume the latest known CUDA version if we've found an unknown one.Artem Belevich2020-01-297-0/+5
| | | | | | | | | | | | | | | | | This makes clang somewhat forward-compatible with new CUDA releases without having to patch it for every minor release without adding any new function. If an unknown version is found, clang issues a warning (can be disabled with -Wno-cuda-unknown-version) and assumes that it has detected the latest known version. CUDA releases are usually supersets of older ones feature-wise, so it should be sufficient to keep released clang versions working with minor CUDA updates without having to upgrade clang, too. Differential Revision: https://reviews.llvm.org/D73231 (cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
* [Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song2020-01-241-3/+5
| | | | | | | | | | __attribute__((patchable_function_entry(N,M))) where M>0 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73072 (cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
* [Clang][IFS][Test] Work around in-process cc1 ASAN issues #2.Mitch Phillips2020-01-231-4/+12
| | | | | | | | | | | | | Using the same strategy as c38e42527b21. D69825 revealed (introduced?) a problem when building with ASan, and some memory leaks somewhere. More details are available in the original patch. Looks like we missed one failing tests, this patch adds the workaround to this test as well. (cherry picked from commit e174da447c180b586719cb28f7bd556e30625762)
* Clang] Fix expansion of response files in -Wp after integrated-cc1 changeAlexandre Ganea2020-01-231-0/+10
| | | | | | | | | | After rGb4a99a061f517e60985667e39519f60186cbb469, passing a response file such as -Wp,@a.rsp wasn't working anymore because .rsp expansion happens inside clang's main() function. This patch adds response file expansion in the -cc1 tool. Differential Revision: https://reviews.llvm.org/D73120 (cherry picked from commit 68d7f06092e56b17eb0cddf560a9d9fe8afb7dd8)
* [PATCH] Reland [Clang] Un-break scan-build after integrated-cc1 changeAlexandre Ganea2020-01-224-7/+8
| | | | | | | | | | | | The issue was reported by @xazax.hun here: https://reviews.llvm.org/D69825#1827826 "This patch (D69825) breaks scan-build-py which parses the output of "-###" to get -cc1 command. There might be other tools with the same problems. Could we either remove (in-process) from CC1Command::Print or add a line break? Having the last line as a valid invocation is valuable and there might be tools relying on that." Differential Revision: https://reviews.llvm.org/D72982 (cherry picked from commit 133a7e631cee97965e310f0d110739217427fd3d)
* Revert "[OPENMP]Do not use RTTI by default for NVPTX devices."Alexey Bataev2020-01-171-20/+0
| | | | | | | This reverts commit 23058f9dd4d7e18239fd63b6da52549514b45fda. It breaks builds of cuda code somehow in some cases. (cherry picked from commit 6b29aa21180cf14bfb619d38fc4826913cabfb66)
* Replace CLANG_SPAWN_CC1 env var with a driver mode flagNico Weber2020-01-161-4/+22
| | | | | | | | | | | | | | | | | | Flags are clang's default UI is flags. We can have an env var in addition to that, but in D69825 nobody has yet mentioned why this needs an env var, so omit it for now. If someone needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1 for example). Also mention the cc1-in-process change in the release notes. Also spruce up the test a bit so it actually tests something :) Differential Revision: https://reviews.llvm.org/D72769 (cherry picked from commit 8e5018e990b701391e6c33ba85b012343df67272)
* [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundariesFangrui Song2020-01-142-0/+52
| | | | | | | | These driver options perform some checking and delegate to MC options -x86-align-branch* and -x86-branches-within-32B-boundaries. Reviewed By: skan Differential Revision: https://reviews.llvm.org/D72463
* Modify test to use -S instead of -c so that it works when an external ↵Douglas Yung2020-01-141-4/+4
| | | | assembler is used that is not present.
* [OPENMP]Do not use RTTI by default for NVPTX devices.Alexey Bataev2020-01-141-0/+20
| | | | NVPTX does not support RTTI, so disable it by default.
* [Driver][test] Fix Driver/hexagon-toolchain-elf.c for ↵Fangrui Song2020-01-141-1/+2
| | | | | | | | -DCLANG_DEFAULT_LINKER=lld builds Reviewed By: nathanchance, sidneym Differential Revision: https://reviews.llvm.org/D72668
* [Driver] Ignore -fno-semantic-interpositionFangrui Song2020-01-141-0/+1
| | | | | | | | | | | | | | | | | | Fedora wants to build projects with -fno-semantic-interposition (e.g. https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup), which is supported by GCC>=5. Clang's current behavior is similar to -fno-semantic-interposition and the end goal is to make it more so (https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html). Ignore this option. We should let users know -fsemantic-interposition is not currently supported, so it should remain a hard error. Reviewed By: serge-sans-paille Differential Revision: https://reviews.llvm.org/D72724
* Fix NetBSD bot after b4a99a061f517e60985667e39519f60186cbb469 ↵Alexandre Ganea2020-01-141-1/+1
| | | | ([Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation)
* [clang] [test] Fix riscv-toolchain-extra to be less picky about pathsMichał Górny2020-01-142-6/+6
| | | | | | | Fix riscv-toolchain-extra tests to pass when CLANG_RESOURCE_DIR is set to another value than the default. Differential Revision: https://reviews.llvm.org/D72591
* [Clang] Always set -z now linker option on FuchsiaPetr Hosek2020-01-132-2/+2
| | | | | | This should be the default on Fuchsia. Differential Revision: https://reviews.llvm.org/D70576
* [Clang][Driver] Re-use the calling process instead of creating a new process ↵Alexandre Ganea2020-01-135-4/+8
| | | | | | | | | | | | | | | for the cc1 invocation With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process. This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus. It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process. Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means. This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process. At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before. Differential Revision: https://reviews.llvm.org/D69825
* This option allows selecting the TLS size in the local exec TLS model,KAWASHIMA Takahiro2020-01-131-0/+26
| | | | | | | | | | | | | | | | | | which is the default TLS model for non-PIC objects. This allows large/ many thread local variables or a compact/fast code in an executable. Specification is same as that of GCC. For example, the code model option precedes the TLS size option. TLS access models other than local-exec are not changed. It means supoort of the large code model is only in the local exec TLS model. Patch By KAWASHIMA Takahiro (kawashima-fj <t-kawashima@fujitsu.com>) Reviewers: dmgreen, mstorsjo, t.p.northover, peter.smith, ostannard Reviewd By: peter.smith Committed by: peter.smith Differential Revision: https://reviews.llvm.org/D71688
* driver: Allow -fdebug-compilation-dir=foo in joined form.Nico Weber2020-01-104-4/+9
| | | | | | | All 130+ f_Group flags that take an argument allow it after a '=', except for fdebug-complation-dir. Add a Joined<> alias so that it behaves consistently with all the other f_Group flags. (Keep the old Separate flag for backwards compat.)
* [Driver][PowerPC] Move powerpcspe logic from cc1 to DriverFangrui Song2020-01-101-1/+4
| | | | | | | | | Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72433
* [Driver][CodeGen] Add -fpatchable-function-entry=N[,0]Fangrui Song2020-01-101-0/+17
| | | | | | | | | | | In the backend, this feature is implemented with the function attribute "patchable-function-entry". Both the attribute and XRay use TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are incompatible. Reviewed By: ostannard, MaskRay Differential Revision: https://reviews.llvm.org/D72222
* [ARM][MVE] MVE-I should not be disabled by -mfpu=noneMomchil Velikov2020-01-091-17/+37
| | | | | | | | | | | | | | | Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
* AArch64: add missing Apple CPU names and use them by default.Tim Northover2020-01-082-3/+3
| | | | | | | | Apple's CPUs are called A7-A13 in official communication, occasionally with weird suffixes which we probably don't need to care about. This adds each one and describes its features. It also switches the default CPU to the canonical name for Cyclone, but leaves legacy support in so that existing bitcode still compiles.
* [PowerPC] Default ppc64 linux-gnu/freebsd to -fno-PICFangrui Song2020-01-071-4/+6
| | | | | | | | | | | | | | | | | According to D53384, the default was switched from -fno-PIC to -fPIC to work around a -fsanitize=leak bug on big-endian. This gratuitous difference between little-endian and big-endian is undesired, and not acceptable on powerpc64-unknown-freebsd. If -fsanitize=leak still has the problem, we should consider defaulting to -fPIC/-fPIE only when -fsanitize=leak is specified (see SanitizerArgs::requiresPIE()) powerpc64-ibm-aix is unaffected: it still defaults to -fPIC. powerpc64-linux-musl is unaffected (-fPIE since D39588): it still defaults to -fPIE. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72363
* [PowerPC][Triple] Use elfv2 on freebsd>=13 and linux-muslFangrui Song2020-01-071-0/+6
| | | | | | | | | | | | | | | | | | | Summary: Every powerpc64le platform uses elfv2. For powerpc64, the environments "elfv1" and "elfv2" were added for FreeBSD ELFv1->ELFv2 migration in D61950. FreeBSD developers have decided to use OS versions to select ABI, and no one is relying on the environments. Also use elfv2 on powerpc64-linux-musl. Users can always use -mabi=elfv1 and -mabi=elfv2 to override the default ABI. Reviewed By: adalava Differential Revision: https://reviews.llvm.org/D72352
* [HIP] Add option --gpu-max-threads-per-block=nYaxun (Sam) Liu2020-01-071-0/+10
| | | | | | Add this option to change the default launch bounds. Differential Revision: https://reviews.llvm.org/D71221
* [Clang] Force rtlib=platform in test to avoid fails with CLANG_DEFAULT_RTLIBKristina Brooks2020-01-061-0/+3
| | | | | | | | | | | | | | | | | | Driver test `cross-linux.c` fails when CLANG_DEFAULT_RTLIB is "compiler-rt" as the it expects a GCC-style `"crtbegin.o"` after `"crti.o"` but instead receives something akin to this in the frontend invocation: ``` "crt1.o" "crti.o" "/o/b/llvm/bin/../lib/clang/10.0.0/lib/linux/clang_rt.crtbegin-x86_64.o" ``` This patch adds an override to `cross-linux.c` tests so the expected result is produced regardless of the compile-time default rtlib, as having tests fail due to that is fairly confusing. After applying the patch, the test passes regardless of the CLANG_DEFAULT_RTLIB setting. Differential Revision: https://reviews.llvm.org/D72236
* [SystemZ] Don't allow CL option -mpacked-stack with -mbackchain.Jonas Paulsson2020-01-031-0/+3
| | | | | | | -mpacked-stack is currently not supported with -mbackchain, so this should result in a compilation error message instead of being silently ignored. Review: Ulrich Weigand
* [Driver] Allow -mnop-mcount for SystemZ and -mfentry for X86 and SystemZFangrui Song2019-12-222-3/+16
| | | | | | | | | | | | | | | | | | | | | | | gcc/config/{i386,s390} support -mnop-mcount. We currently only support -mnop-mcount for SystemZ. The function attribute "mnop-mcount" is ignored on other targets. gcc/config/{i386,s390} support -mfentry. We currently only support -mfentry for X86 and SystemZ. TargetOpcode::FENTRY_CALL is not handled on other targets. % clang -target aarch64 -pg -mfentry a.c -c fatal error: error in backend: Not supported instr: <MCInst 21> -mfentry, -mrecord-mcount, and -mnop-mcount were invented for Linux ftrace. Linux uses $(call cc-option-yn,-mrecord-mcount) to detect if the specific feature is available. Reject unsupported features so that Linux build system will not wrongly consider them available and cause build/runtime failures. Note, GCC has stricter checks that we do not implement, e.g. -fpic/-fpie -fnop-mcount is not allowed on x86, -fpic/-fpie -mfentry is not allowed on x86-32.
* [Driver] Verify -mrecord-mcount in Driver, instead of CodeGen after D71627Fangrui Song2019-12-211-0/+8
| | | | | | | | | | | GCC's x86 and s390 ports support -mrecord-mcount. Other ports reject the option. aarch64-linux-gnu-gcc: error: unrecognized command line option ‘-mrecord-mcount’ Allowing this option can cause failures when building Linux kernel for aarch64, powerpc64, etc, which will think the feature is available if the clang command returns 0.
* Add missing `REQUIRES: hexagon-registered-target`David Zarzycki2019-12-211-0/+1
| | | | | After d567b0ba841d4b6f4b0d906da350a3bb2b2f769f, the test suite no longer passes if hexagon is disabled.
* Avoid unsupported LLD optionsSid Manning2019-12-202-0/+22
| | | | Differential Revision: https://reviews.llvm.org/D70919
* [NFC][Driver] Add dummy compiler-rt sanitizer dylibs for Darwin.Dan Liew2019-12-2031-0/+0
| | | | | | | This adds dummy files to the test resource directory used by the Clang driver tests. rdar://problem/58118584
* Re-land "Add an -fno-temp-file flag for compilation"Hans Wennborg2019-12-191-0/+3
| | | | | | | | This time making sure to initialize FrontendOptions::UseTemporary. Patch by Zachary Henkel! Differential revision: https://reviews.llvm.org/D70615
* [Remarks][Driver] Place temporary remark files next to temporary object filesFrancis Visoiu Mistrih2019-12-181-0/+7
| | | | | | | | | | | On Darwin, when used for generating a linked binary from a source file (through an intermediate object file), the driver will invoke `cc1` to generate a temporary object file. The temporary remark file will now be emitted next to the object file, which will then be picked up by `dsymutil` and emitted in the .dSYM bundle. This is available for all formats except YAML since by default, YAML doesn't need a section and the remark file will be lost.
* [Remarks][Driver] Run dsymutil when remarks are enabledFrancis Visoiu Mistrih2019-12-181-0/+13
| | | | | | | | | When clang is invoked with a source file without -c or -S, it creates a cc1 job, a linker job and if debug info is requested, a dsymutil job. In case of remarks, we should also create a dsymutil job to avoid losing the remarks that will be generated in a tempdir that gets removed. Differential Revision: https://reviews.llvm.org/D71675
OpenPOWER on IntegriCloud