Summary:
Basic support of Sanitiser to follow-up ubsan support in compiler-rt.
Needs to use lld instead of base ld to be fully workable.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, kettenis
Reviewed By: vitalybuka
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43961
llvm-svn: 326648
This makes it easier to debug crashes and hangs in block functions since
users can easily find out where the block is called from. The option
doesn't disable tail-calls from non-escaping blocks since non-escaping
blocks are not as hard to debug as escaping blocks.
rdar://problem/35758207
Differential Revision: https://reviews.llvm.org/D43841
llvm-svn: 326530
Since LLVM r326341, default EmulatedTLS mode is decided in backend
according to target triple. Any front-end should pass -f[no]-emulated-tls
to backend and set up ExplicitEmulatedTLS only when the flags are used.
Differential Revision: https://reviews.llvm.org/D43965
llvm-svn: 326499
Differential Revision: https://reviews.llvm.org/D43852
This patch extends the SPMD implementation to all target constructs and guards this implementation under a new flag.
llvm-svn: 326368
Binaries for multiple architectures are combined by fatbinary,
so the current code was effectively not needed.
Differential Revision: https://reviews.llvm.org/D43461
llvm-svn: 326342
In these combinations, link a DLL as usual, but pass -Bstatic instead
of -Bdynamic to indicate prefering static libraries.
Differential Revision: https://reviews.llvm.org/D43811
llvm-svn: 326235
Return a new CompilerRT Path on NetBSD: "netbsd", instead of
getOS(), which returns a string like "netbsd8.9.12".
Sponsored by <The NetBSD Foundation>
llvm-svn: 326219
clang used to require adding an ".exe" suffix when targeting ELF systems on Windows.
Differential Revision: https://reviews.llvm.org/D43621
llvm-svn: 326164
This allows reporting an error when user tries to use SafeStack with
incompatible sanitizers.
Differential Revision: https://reviews.llvm.org/D43606
llvm-svn: 326151
This reverts commit e17911006548518634fad66bb8648bcad49a1d64.
This is failing on ASAN bots because asan expects column info,
and it's also failing on some linux bots for unknown reasons which
i need to investigate.
llvm-svn: 326116
Windows debuggers don't work properly when column info is emitted
with lines. We handled this by checking if the driver mode was
cl, but it's possible to cause the gcc driver to emit codeview as
well, and in that path we were emitting column info with codeview.
Differential Revision: https://reviews.llvm.org/D43700
llvm-svn: 326113
In DWARF v5 the Line Number Program Header is extensible, allowing values with
new content types. This vendor extension to DWARF v5 allows source text to be
embedded directly in the line tables of the debug line section.
Add new flag (-g[no-]embed-source) to Driver and CC1 which indicates
that source should be passed through to LLVM during CodeGen.
Differential Revision: https://reviews.llvm.org/D42766
llvm-svn: 326102
Summary:
If the flag -fforce-enable-int128 is passed, it will enable support for __int128_t and __uint128_t types.
This flag can then be used to build compiler-rt for RISCV32.
Reviewers: asb, kito-cheng, apazos, efriedma
Reviewed By: asb, efriedma
Subscribers: shiva0217, efriedma, jfb, dschuff, sdardis, sbc100, jgravelle-google, aheejin, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, cfe-commits
Differential Revision: https://reviews.llvm.org/D43105
llvm-svn: 326045
Summary:
OpenCL 2.0 specification defines '-cl-uniform-work-group-size' option,
which requires that the global work-size be a multiple of the work-group
size specified to clEnqueueNDRangeKernel and allows optimizations that
are made possible by this restriction.
The patch introduces the support of this option.
To keep information about whether an OpenCL kernel has uniform work
group size or not, clang generates 'uniform-work-group-size' function
attribute for every kernel:
- "uniform-work-group-size"="true" for OpenCL 1.2 and lower,
- "uniform-work-group-size"="true" for OpenCL 2.0 and higher if
'-cl-uniform-work-group-size' option was specified,
- "uniform-work-group-size"="false" for OpenCL 2.0 and higher if no
'-cl-uniform-work-group-size' options was specified.
If the function is not an OpenCL kernel, 'uniform-work-group-size'
attribute isn't generated.
Patch by: krisb
Reviewers: yaxunl, Anastasia, b-sumner
Reviewed By: yaxunl, Anastasia
Subscribers: nhaehnle, yaxunl, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D43570
llvm-svn: 325771
Summary:
- Using -lpthread instead, with -pthread the linkage does not work.
-Warning about the -fxray-instrument usage outside of the working cases.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, dberris, emaste
Reviewed By: krytarowski, emaste
Subscribers: srhines, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D43378
llvm-svn: 325746
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
llvm-svn: 325651
Ideally, we'd only use the ubsan blacklist for ubsan sanitizers, and only use
the other-sanitizer blacklist for its sanitizers, but this at least enables the
intended suppressions.
llvm-svn: 325640
The proper approach is to rebuild libutil and libkvm with a desired sanitizer.
An alternative approach to reimplement these functions (and other ones like
curses(3), editline(3) etc) does not scale and enforces linkage every single
binary with these libraries.
llvm-svn: 325593
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/D42569
llvm-svn: 325492
Summary:
FreeBSD N64 MIPS systems can include 32-bit libraries for O32 in
/usr/lib32 similar to the 32-bit compatibility libraries provided
for FreeBSD/amd64 and FreeBSD/powerpc64.
Reviewers: dim
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D42972
llvm-svn: 324948
As a first step, pass '-c/--compile-only' to ptxas so that it
doesn't complain about references to external function. This
will successfully generate object files, but they won't work
at runtime because the registration routines need to adapted.
Differential Revision: https://reviews.llvm.org/D42921
llvm-svn: 324878
LLDB creates Clang modules and had an incomplete copy of the clang
Driver code that compute the -fmodule-cache-path. This patch makes the
clang driver code accessible to LLDB.
Differential Revision: https://reviews.llvm.org/D43128
llvm-svn: 324761
Summary:
Currently, assertion-disabled Clang builds emit value names when generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not easily overridable. In order to get IR output containing names from a release build of Clang, the user must manually construct the CC1 invocation w/o the `-discard-value-names` option. This is less than ideal.
For example, Godbolt uses a release build of Clang, and so when asked to emit LLVM IR the result lacks names, making it harder to read. Manually invoking CC1 on Compiler Explorer is not feasible.
This patch adds the driver options `-fdiscard-value-names` and `-fno-discard-value-names` which allow the user to override the default behavior. If neither is specified, the old behavior remains.
Reviewers: erichkeane, aaron.ballman, lebedev.ri
Reviewed By: aaron.ballman
Subscribers: bogner, cfe-commits
Differential Revision: https://reviews.llvm.org/D42887
llvm-svn: 324498
This bit of code in the driver uses '~0U' as a sentinel value.
The result is an odd mishmash of casts just to work. This replaces
it with an optional, which is a little less crazy looking.
--ehis line, and those below, will be ignored--
M lib/Driver/Driver.cpp
llvm-svn: 324433
Summary:
During make check-all on Solaris, I see several instances of this warning:
clang-6.0: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
Since Solaris 10, libpthread has been folded into libc, so there's nothing to do. gcc
just ignores -pthread here. Darwin claims the option to silence the warning, and
this patch follows that lead.
Reviewers: rsmith, fedor.sergeev
Reviewed By: fedor.sergeev
Subscribers: cfe-commits, fedor.sergeev
Differential Revision: https://reviews.llvm.org/D41242
llvm-svn: 324344
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
If the CUDA toolkit is not installed to its default locations
in /usr/local/cuda, the user is forced to specify --cuda-path.
This is tedious and the driver can be smarter if well-known tools
(like ptxas) can already be found in the PATH environment variable.
Add option --cuda-path-ignore-env if the user wants to ignore
set environment variables. Also use it in the tests to make sure
the driver always finds the same CUDA installation, regardless
of the user's environment.
Differential Revision: https://reviews.llvm.org/D42642
llvm-svn: 323848
Clang can use CUDA-9.1 now, though new APIs (are not implemented yet.
The major change is that headers in CUDA-9.1 went through substantial
changes that started in CUDA-9.0 which required substantial changes
in the cuda compatibility headers provided by clang.
There are two major issues:
* CUDA SDK no longer provides declarations for libdevice functions.
* A lot of device-side functions have become nvcc's builtins and
CUDA headers no longer contain their implementations.
This patch changes the way CUDA headers are handled if we compile
with CUDA 9.x. Both 9.0 and 9.1 are affected.
* Clang provides its own declarations of libdevice functions.
* For CUDA-9.x clang now provides implementation of device-side
'standard library' functions using libdevice.
This patch should not affect compilation with CUDA-8. There may be
some observable differences for CUDA-9.0, though they are not expected
to affect functionality.
Tested: CUDA test-suite tests for all supported combinations of:
CUDA: 7.0,7.5,8.0,9.0,9.1
GPU: sm_20, sm_35, sm_60, sm_70
Differential Revision: https://reviews.llvm.org/D42513
llvm-svn: 323713
For /arch:AVX512F:
clang-cl and cl.exe both defines __AVX512F__ __AVX512CD__.
clang-cl also defines __AVX512ER__ __AVX512PF__.
64-bit cl.exe also defines (according to /Bz) _NO_PREFETCHW.
For /arch:AVX512:
clang-cl and cl.exe both define
__AVX512F__ __AVX512CD__ __AVX512BW__ __AVX512DQ__ __AVX512VL__.
64-bit cl.exe also defines _NO_PREFETCHW.
So not 100% identical, but pretty close.
Also refactor the existing AVX / AVX2 code to not repeat itself in both the
32-bit and 64-bit cases.
https://reviews.llvm.org/D42538
llvm-svn: 323433
r213083 initially implemented /arch: support by mapping it to CPU features.
Then r241077 additionally mapped it to CPU, which made the feature flags
redundant (if harmless). This change here removes the redundant mapping to
feature flags, and rewrites test/Driver/cl-x86-flags.c to be a bit more of an
integration test that checks for preprocessor defines like AVX (like documented
on MSDN) instead of for driver flags.
To keep emitting warn_drv_unused_argument, use getLastArgNoClaim() followed by an explicit claim() if needed.
This is in preparation for adding support for /arch:AVX512(F).
No intended behavior change.
https://reviews.llvm.org/D42497
llvm-svn: 323426
r317337 missed that scudo is supported on MIPS32, so permit that option for
MIPS32.
Reviewers: cryptoad, atanasyan
Differential Revision: https://reviews.llvm.org/D42416
llvm-svn: 323412
NVPTX does not have runtime support necessary for profiling to work
and even call arc collection is prohibitively expensive. Furthermore,
there's no easy way to collect the samples. NVPTX also does not
support global constructors that clang generates if sample/arc collection
is enabled.
Differential Revision: https://reviews.llvm.org/D42452
llvm-svn: 323345
Summary:
This patch is meant to address the last outstanding review comment on the already approved
(but not yet commited) https://reviews.llvm.org/D35755, namely making the handling of the RHEL
devtoolsets Linux-specific.
Don't know if it's best integrated into the former or applied subsequently.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
Reviewers: fedor.sergeev, tstellar, jyknight
Reviewed By: fedor.sergeev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42029
llvm-svn: 323194
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
Summary:
kvm - kernel memory interface
The kvm(3) functions like kvm_open(), kvm_getargv() or kvm_getenvv()
are used in programs that can request information about a kernel and
its processes. The LLVM sanitizers will make use of them on NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, dvyukov
Reviewed By: vitalybuka
Subscribers: llvm-commits, cfe-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D42017
llvm-svn: 323022
When using -fno-integrated-as flag, the gnu assembler produces code
with some default march/mabi which later causes linker failure due
to incompatible mabi/march.
In this patch we explicitly propagate -mabi and -march flags to the
GNU assembler.
In this patch we explicitly propagate -mabi and -march flags to the GNU assembler.
Differential Revision: https://reviews.llvm.org/D41271
llvm-svn: 322769
Referenced implementation from Fuchsia and Darwin Toolchain.
Still only support CST_Libcxx. Now checks that the argument
is really '-stdlib=libc++', and display error.
Also, now will pass -lc++ and -lc++abi to the linker.
Patch by Patrick Cheng!
Differential Revision: https://reviews.llvm.org/D41937
llvm-svn: 322382
As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver
support (RV64 to follow).
Differential Revision: https://reviews.llvm.org/D39963
llvm-svn: 322276
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
The original patch didn't have the lit.local.cfg file that restricts the new
test to x86, thus the new test was failing on the non-x86 bots.
Differential Revision: https://reviews.llvm.org/D40531
The reverts r322008, which was a revert of r322005.
This reverts commit a05b89f9aca70597dc79fe97bc49b50b51f525ba.
llvm-svn: 322136
The Ananas Operating System (https://github.com/zhmu/ananas) has shared
library support as of commit 57739c0b6ece56dd4872aedf30264ed4b9412c77.
This change adds the necessary settings to clang so that shared
executables and libraries can be build correctly.
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D41500
llvm-svn: 322064
Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc.
For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions.
Differential Revision: https://reviews.llvm.org/D40478
Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea
llvm-svn: 322063
Summary:
The flag has been deprecated, and is becoming invalid in the latest
MDK.
Reviewers: jyknight
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41713
llvm-svn: 322023
The new test fails on the Hexagon bot. Reverting while I investigate.
This reverts https://reviews.llvm.org/rL322005
This reverts commit b7e0026b4385180c378edc658ec91a39566f2942.
llvm-svn: 322008
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
Differential Revision: https://reviews.llvm.org/D40531
llvm-svn: 322005
Adds the -fstack-size-section flag to enable the .stack_sizes section. The flag defaults to on for the PS4 triple.
Differential Revision: https://reviews.llvm.org/D40712
llvm-svn: 321992
Summary:
Depends on https://reviews.llvm.org/D41732.
Utilities such as `opt`, when invoked with arguments that are very
nearly spelled correctly, suggest the correctly spelled options:
```
bin/opt -hel
opt: Unknown command line argument '-hel'. Try: 'bin/opt -help'
opt: Did you mean '-help'?
```
Clang, on the other hand, prior to this commit, does not:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel'
```
This commit makes use of the new libLLVMOption API from
https://reviews.llvm.org/D41732 in order to provide correct suggestions:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel', did you mean '-help'?
```
Test Plan: `check-clang`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, bruno
Reviewed By: bruno
Subscribers: bruno, jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D41733
llvm-svn: 321917
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
llvm-svn: 321621
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
llvm-svn: 321587
-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`
llvm-svn: 321559
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
llvm-svn: 321099
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
llvm-svn: 321090
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
llvm-svn: 321080
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
llvm-svn: 320920
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
llvm-svn: 320419
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
llvm-svn: 320391
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
llvm-svn: 320235
Kamil Rytarowski