summaryrefslogtreecommitdiff
path: root/test/Driver
AgeCommit message (Collapse)Author
2018-04-11Merging r325651:llvm_60-amp-20180630release_60-f1b37feef3d-amp-20180630Simon Dardis
------------------------------------------------------------------------ r325651 | sdardis | 2018-02-21 00:05:05 +0000 (Wed, 21 Feb 2018) | 34 lines [mips] Spectre variant two mitigation for MIPSR2 This patch provides mitigation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It provides the option -mindirect-jump=hazard, which instructs the LLVM backend to replace indirect branches with their hazard barrier variants. This option is accepted when targeting MIPS revision two or later. The migitation strategy suggested by MIPS for these processors is to use two hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are used with the option -mindirect-jump=hazard when branching indirectly and for indirect function calls. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. Implementation note: I've opted to provide this as an -mindirect-jump={hazard,...} style option in case alternative mitigation methods are required for other implementations of the MIPS ISA in future, e.g. retpoline style solutions. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D43487 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@329799 91177308-0d34-0410-b5e6-96231b3b80d8
2018-02-02Merging r323155:Hans Wennborg
------------------------------------------------------------------------ r323155 | chandlerc | 2018-01-22 23:05:25 +0100 (Mon, 22 Jan 2018) | 133 lines Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.. Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain. The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers. However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address. On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address. This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886 We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction. There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection. The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness. For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller. When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typical workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel. When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline. We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors. This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design. Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D41723 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@324068 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-30Merging r323360:Hans Wennborg
------------------------------------------------------------------------ r323360 | kparzysz | 2018-01-24 19:42:19 +0100 (Wed, 24 Jan 2018) | 2 lines [Hexagon] Accept lowercase b in -hvx-length=64b and -hvx-length=128b ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@323769 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-30Merging r323485:Hans Wennborg
------------------------------------------------------------------------ r323485 | aemerson | 2018-01-26 01:27:22 +0100 (Fri, 26 Jan 2018) | 3 lines [Driver] Add an -fexperimental-isel driver option to enable/disable GlobalISel. Differential Revision: https://reviews.llvm.org/D42276 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@323745 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-02[Driver] Fix unused variables and test-writing-into-workdir after r321621Sam McCall
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321639 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-01Enable configuration files in clangSerge Pavlov
Clang is inherently a cross compiler and can generate code for any target enabled during build. It however requires to specify many parameters in the invocation, which could be hardcoded during configuration process in the case of single-target compiler. The purpose of configuration files is to make specifying clang arguments easier. A configuration file is a collection of driver options, which are inserted into command line before other options specified in the clang invocation. It groups related options together and allows specifying them in simpler, more flexible and less error prone way than just listing the options somewhere in build scripts. Configuration file may be thought as a "macro" that names an option set and is expanded when the driver is called. Use of configuration files is described in `UserManual.rst`. Differential Revision: https://reviews.llvm.org/D24933 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321621 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-30Reverted 321587: Enable configuration files in clangSerge Pavlov
Need to check targets in tests more carefully. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321588 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-30Enable configuration files in clangSerge Pavlov
Clang is inherently a cross compiler and can generate code for any target enabled during build. It however requires to specify many parameters in the invocation, which could be hardcoded during configuration process in the case of single-target compiler. The purpose of configuration files is to make specifying clang arguments easier. A configuration file is a collection of driver options, which are inserted into command line before other options specified in the clang invocation. It groups related options together and allows specifying them in simpler, more flexible and less error prone way than just listing the options somewhere in build scripts. Configuration file may be thought as a "macro" that names an option set and is expanded when the driver is called. Use of configuration files is described in `UserManual.rst`. Differential Revision: https://reviews.llvm.org/D24933 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321587 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-29[driver][darwin] Take the OS version from -m<os>-version-min argument whenAlex Lorenz
-target has no OS version This ensures that Clang won't warn about redundant -m<os>-version-min argument for an invocation like `-target x86_64-apple-macos -mmacos-version-min=10.11` git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321559 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[x86][icelake][vbmi2]Coby Tayree
added vbmi2 feature recognition added intrinsics support for vbmi2 instructions _mm[128,256,512]_mask[z]_compress_epi[16,32] _mm[128,256,512]_mask_compressstoreu_epi[16,32] _mm[128,256,512]_mask[z]_expand_epi[16,32] _mm[128,256,512]_mask[z]_expandloadu_epi[16,32] _mm[128,256,512]_mask[z]_sh[l,r]di_epi[16,32,64] _mm[128,256,512]_mask_sh[l,r]dv_epi[16,32,64] matching a similar work on the backend (D40206) Differential Revision: https://reviews.llvm.org/D41557 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321487 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[x86][icelake][vnni]Coby Tayree
added vnni feature recognition added intrinsics support for VNNI instructions _mm256_mask_dpbusd_epi32 _mm256_maskz_dpbusd_epi32 _mm256_dpbusd_epi32 _mm256_mask_dpbusds_epi32 _mm256_maskz_dpbusds_epi32 _mm256_dpbusds_epi32 _mm256_mask_dpwssd_epi32 _mm256_maskz_dpwssd_epi32 _mm256_dpwssd_epi32 _mm256_mask_dpwssds_epi32 _mm256_maskz_dpwssds_epi32 _mm256_dpwssds_epi32 _mm128_mask_dpbusd_epi32 _mm128_maskz_dpbusd_epi32 _mm128_dpbusd_epi32 _mm128_mask_dpbusds_epi32 _mm128_maskz_dpbusds_epi32 _mm128_dpbusds_epi32 _mm128_mask_dpwssd_epi32 _mm128_maskz_dpwssd_epi32 _mm128_dpwssd_epi32 _mm128_mask_dpwssds_epi32 _mm128_maskz_dpwssds_epi32 _mm128_dpwssds_epi32 _mm512_mask_dpbusd_epi32 _mm512_maskz_dpbusd_epi32 _mm512_dpbusd_epi32 _mm512_mask_dpbusds_epi32 _mm512_maskz_dpbusds_epi32 _mm512_dpbusds_epi32 _mm512_mask_dpwssd_epi32 _mm512_maskz_dpwssd_epi32 _mm512_dpwssd_epi32 _mm512_mask_dpwssds_epi32 _mm512_maskz_dpwssds_epi32 _mm512_dpwssds_epi32 matching a similar work on the backend (D40208) Differential Revision: https://reviews.llvm.org/D41558 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321484 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[x86][icelake][bitalg]Coby Tayree
added bitalg feature recognition added intrinsics support for bitalg instructions _mm512_popcnt_epi16 _mm512_mask_popcnt_epi16 _mm512_maskz_popcnt_epi16 _mm512_popcnt_epi8 _mm512_mask_popcnt_epi8 _mm512_maskz_popcnt_epi8 _mm512_mask_bitshuffle_epi64_mask _mm512_bitshuffle_epi64_mask _mm256_popcnt_epi16 _mm256_mask_popcnt_epi16 _mm256_maskz_popcnt_epi16 _mm128_popcnt_epi16 _mm128_mask_popcnt_epi16 _mm128_maskz_popcnt_epi16 _mm256_popcnt_epi8 _mm256_mask_popcnt_epi8 _mm256_maskz_popcnt_epi8 _mm128_popcnt_epi8 _mm128_mask_popcnt_epi8 _mm128_maskz_popcnt_epi8 _mm256_mask_bitshuffle_epi32_mask _mm256_bitshuffle_epi32_mask _mm128_mask_bitshuffle_epi16_mask _mm128_bitshuffle_epi16_mask matching a similar work on the backend (D40222) Differential Revision: https://reviews.llvm.org/D41564 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321483 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[hotfix]Coby Tayree
fixinig test failures as seen here: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/22791/steps/test/logs/stdio which resulted by rL321480 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321482 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[x86][icelake][vpclmulqdq]Coby Tayree
added vpclmulqdq feature recognition added intrinsics support for vpclmulqdq instructions _mm256_clmulepi64_epi128 _mm512_clmulepi64_epi128 matching a similar work on the backend (D40101) Differential Revision: https://reviews.llvm.org/D41573 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321480 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[x86][icelake][gfni]Coby Tayree
added gfni feature recognition added intrinsics support for gfni instructions _mm_gf2p8affineinv_epi64_epi8 _mm_mask_gf2p8affineinv_epi64_epi8 _mm_maskz_gf2p8affineinv_epi64_epi8 _mm256_gf2p8affineinv_epi64_epi8 _mm256_mask_gf2p8affineinv_epi64_epi8 _mm256_maskz_gf2p8affineinv_epi64_epi8 _mm512_gf2p8affineinv_epi64_epi8 _mm512_mask_gf2p8affineinv_epi64_epi8 _mm512_maskz_gf2p8affineinv_epi64_epi8 _mm_gf2p8affine_epi64_epi8 _mm_mask_gf2p8affine_epi64_epi8 _mm_maskz_gf2p8affine_epi64_epi8 _mm256_gf2p8affine_epi64_epi8 _mm256_mask_gf2p8affine_epi64_epi8 _mm256_maskz_gf2p8affine_epi64_epi8 _mm512_gf2p8affine_epi64_epi8 _mm512_mask_gf2p8affine_epi64_epi8 _mm512_maskz_gf2p8affine_epi64_epi8 _mm_gf2p8mul_epi8 _mm_mask_gf2p8mul_epi8 _mm_maskz_gf2p8mul_epi8 _mm256_gf2p8mul_epi8 _mm256_mask_gf2p8mul_epi8 _mm256_maskz_gf2p8mul_epi8 _mm512_gf2p8mul_epi8 _mm512_mask_gf2p8mul_epi8 _mm512_maskz_gf2p8mul_epi8 matching a similar work on the backend (D40373) Differential Revision: https://reviews.llvm.org/D41582 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321477 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-27[x86][icelake][vaes]Coby Tayree
added vaes feature recognition added intrinsics support for vaes instructions, matching a similar work on the backend (D40078) _mm256_aesenc_epi128 _mm512_aesenc_epi128 _mm256_aesenclast_epi128 _mm512_aesenclast_epi128 _mm256_aesdec_epi128 _mm512_aesdec_epi128 _mm256_aesdeclast_epi128 _mm512_aesdeclast_epi128 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321474 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-21[scudo] Add -fsanitize=scudo option to FuchsiaPetr Hosek
Apparently the -fsanitize flag hadn't been added for Scudo upstream yet. Patch By: flowerhack Reviewers: cryptoad, alekseyshl, mcgrathr, phosek Reviewed By: mcgrathr, phosek Differential Revision: https://reviews.llvm.org/D41413 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321314 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-21[Driver] Ensure no overlap between trapping & recoverable sanitizers. NFC.Vedant Kumar
This is NFC because in EmitCheck(), -fsanitize-trap=X overrides -fsanitize-recover=X. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321230 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-20[darwin][driver] Warn about mismatching -<os>-version-min rather thanAlex Lorenz
superfluous -<os>-version-min compiler option rdar://35813850 Differential Revision: https://reviews.llvm.org/D41425 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321145 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-19[driver][darwin] Set the 'simulator' environment when it's specifiedAlex Lorenz
in '-target' rdar://35742458 Differential Revision: https://reviews.llvm.org/D41076 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321102 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-19[driver][darwin] Take the OS version specified in "-target" as the targetAlex Lorenz
OS instead of inferring it from SDK / environment The OS version is specified in -target should be used instead of the one in an environment variable / SDK name. rdar://35813850 Differential Revision: https://reviews.llvm.org/D40998 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321099 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-19[clang] -foptimization-record-file= should imply -fsave-optimization-recordJonas Devlieghere
The Clang option -foptimization-record-file= controls which file an optimization record is output to. Optimization records are output if you use the Clang option -fsave-optimization-record. If you specify the first option without the second, you get a warning that the command line argument was unused. Passing -foptimization-record-file= should imply -fsave-optimization-record. This fixes PR33670 Patch by: Dmitry Venikov <venikov@phystech.edu> Differential revision: https://reviews.llvm.org/D39834 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321090 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-19Add renamed .o files that were omitted by "git llvm push" commandWalter Lee
Original commit is at: https://reviews.llvm.org/D41295. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321082 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-19Rename sparc-myriad-elf triplet to sparc-myriad-rtemsWalter Lee
Summary: This is to be consistent with latest Movidius MDK releases. Also, don't inherit any gcc paths for shave triple. Reviewers: jyknight Subscribers: emaste, fedor.sergeev Differential Revision: https://reviews.llvm.org/D41295 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321080 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-16[Driver, CodeGen] pass through and apply -fassociative-mathSanjay Patel
There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320920 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-13[Hexagon] Add front-end support for Hexagon V65Krzysztof Parzyszek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320579 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-12Add --cuda-path to mock a CUDA Toolkit installation to avoidKelvin Li
unexpected error messages for incompatibility between the default SM level and the support in the installed toolkit. Differential Revision: https://reviews.llvm.org/D40996 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320506 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-11[Driver][CodeGen] Add -mprefer-vector-width driver option and attribute ↵Craig Topper
during CodeGen. This adds a new command line option -mprefer-vector-width to specify a preferred vector width for the vectorizers. Valid values are 'none' and unsigned integers. The driver will check that it meets those constraints. Specific supported integers will be managed by the targets in the backend. Clang will take the value and add it as a new function attribute during CodeGen. This represents the alternate direction proposed by Sanjay in this RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-November/118734.html The syntax here matches gcc, though gcc treats it as an x86 specific command line argument. gcc only allows values of 128, 256, and 512. I'm not having clang check any values. Differential Revision: https://reviews.llvm.org/D40230 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320419 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-11Revert 320391: Certain targets are failing, pulling back to diagnose.Erich Keane
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320398 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-11For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is availableErich Keane
As reported in llvm bugzilla 32377. Here’s a patch to add preinclude of stdc-predef.h. The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html; The preinclude is inhibited with –ffreestanding. Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior. I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here Note: this is a recommit after a test failure took down the original (r318669) Patch By: mibintc Differential Revision: https://reviews.llvm.org/D34158 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320391 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-09Fix Driver/darwin-version.c testAlex Lorenz
A target argument should be provided to avoid failures on non-Darwin git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320238 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-09[driver][darwin] Refactor the target selection code, NFCAlex Lorenz
The simulator variant of Darwin's platforms is removed in favor of a new environment field. The code that selects the platform and the version is split into 4 different functions instead of being all in one function. This is an NFC commit, although it slightly improves the "invalid version number" diagnostic by displaying the environment variable instead of -m<os>-version-min if the OS version was derived from the environment. rdar://35813850 Differential Revision: https://reviews.llvm.org/D41035 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320235 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-09Fix fsanitize-blacklist test on Windows.Evgeniy Stepanov
Broken in r320232. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320233 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-09Hardware-assisted AddressSanitizer (clang part).Evgeniy Stepanov
Summary: Driver, frontend and LLVM codegen for HWASan. A clone of ASan, basically. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D40936 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320232 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-07Correct line endings that got mixed up in r320089; NFC.Aaron Ballman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320113 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-07Add new language mode flags for C17.Aaron Ballman
This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320089 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-07[driver] Set the 'simulator' environment for Darwin when compiling forAlex Lorenz
iOS/tvOS/watchOS simulator rdar://35135215 Differential Revision: https://reviews.llvm.org/D40682 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320073 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-30Revert [ARM] disable FPU features when using soft floating point.Keith Walker
This reverts r319420 It is failing the test Driver/arm-mfpu.c so reverting while I investigate the failure. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319425 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-30[ARM] disable FPU features when using soft floating point.Keith Walker
To be compatible with GCC if soft floating point is in effect any FPU specified is effectively ignored, eg, -mfloat-abi=soft -fpu=neon If any floating point features which require FPU hardware are enabled they must be disable. There was some support for doing this for NEON, but it did not handle VFP, nor did it prevent the backend from emitting the build attribute Tag_FP_arch describing the generated code as using the floating point hardware if a FPU was specified (even though soft float does not use the FPU). Disabling the hardware floating point features for targets which are compiling for soft float has meant that some tests which were incorrectly checking for hardware support also needed to be updated. In such cases, where appropriate the tests have been updated to check compiling for soft float and a non-soft float variant (usually softfp). This was usually because the target specified in the test defaulted to soft float. Differential Revision: https://reviews.llvm.org/D40256 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319420 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-29[Driver] Turns out the GNU assembler does support falkor/saphira.Chad Rosier
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319323 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-27[clang-cl] Alias /Wall to -WeverythingReid Kleckner
cl interprets this option to mean enable every supported warning, which is what Clang's -Weverything flag does. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319116 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-27Switch CPU names not recognized by GNU assemblerPirama Arumuga Nainar
Summary: Switch CPU names not recognized by GNU assembler to a close CPU that it does recognize. In this patch, kryo, falkor and saphira all get replaced by cortex-a57 when invoking the assembler. In addition, krait was already being replaced by cortex-a15. Reviewers: weimingz Subscribers: srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D40476 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319077 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-26Control-Flow Enforcement Technology - Shadow Stack and Indirect Branch ↵Oren Ben Simhon
Tracking support (Clang side) Shadow stack solution introduces a new stack for return addresses only. The stack has a Shadow Stack Pointer (SSP) that points to the last address to which we expect to return. If we return to a different address an exception is triggered. This patch includes shadow stack intrinsics as well as the corresponding CET header. It includes CET clang flags for shadow stack and Indirect Branch Tracking. For more information, please see the following: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Differential Revision: https://reviews.llvm.org/D40224 Change-Id: I79ad0925a028bbc94c8ecad75f6daa2f214171f1 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318995 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-22[Driver] Make the use of relax relocations a per target optionPetr Hosek
The support for relax relocations is dependent on the linker and different toolchains within the same compiler can be using different linkers some of which may or may not support relax relocations. Give toolchains the option to control whether they want to use relax relocations in addition to the existing (global) build system option. Differential Revision: https://reviews.llvm.org/D39831 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318816 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-21Add target triples to openmp-offload-gpu.cJonas Hahnfeld
This might fix the failure on Green Dragon. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318767 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-21[OpenMP] Consistently use cubin extension for nvlinkJonas Hahnfeld
This was previously done in some places, but for example not for bundling so that single object compilation with -c failed. In addition cubin was used for all file types during unbundling which is incorrect for assembly files that are passed to ptxas. Tighten up the tests so that we can't regress in that area. Differential Revision: https://reviews.llvm.org/D40250 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318763 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-20Revert r318669/318694Erich Keane
Broke some libclang tests, so reverting for now. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318698 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-20Include test files for rL318668Erich Keane
Forgotten when doing my SVN commit. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318694 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-20For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is availableErich Keane
As reported in llvm bugzilla 32377. Here’s a patch to add preinclude of stdc-predef.h. The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html; The preinclude is inhibited with –ffreestanding. Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior. I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here Patch By: mibintc Differential Revision: https://reviews.llvm.org/D34158 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318669 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-20[ARM] For assembler files recognize -Xassembler or -Wa, -mthumbPeter Smith
The Unified Arm Assembler Language is designed so that the majority of assembler files can be assembled for both Arm and Thumb with the choice made as a compilation option. The way this is done in gcc is to pass -mthumb to the assembler with either -Wa,-mthumb or -Xassembler -mthumb. This change adds support for these options to clang. There is no assembler equivalent of -mno-thumb, -marm or -mno-arm so we don't need to recognize these. Ideally we would do all of the processing in CollectArgsForIntegratedAssembler(). Unfortunately we need to change the triple and at that point it is too late. Instead we look for the option earlier in ComputeLLVMTriple(). Fixes PR34519 Differential Revision: https://reviews.llvm.org/D40127 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318647 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-12 12:03:44 +0000