GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mtune option for the AArch64 target.
Differential Revision: http://reviews.llvm.org/D10563
llvm-svn: 242663
Summary:
This is a minimal toolchain, which sets the integrated assembler as default,
and uses lld for linking.
Reviewers: arsenm, mcrosier
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10700
llvm-svn: 242601
Currently, -save-temp will cause ObjCARC optimization to be dropped,
sanitizer pass to run early in the pipeline, and profiling
instrumentation to run twice.
Fix the issue by properly disable all passes in the optimization
pipeline when generating bitcode output and parse some of the Language
Options even when the input is bitcode so the passes can be setup
correctly.
llvm-svn: 242565
Guessing which file name to replace based on the -main-file-name
argument to -cc1 is flawed. Instead, keep track of which arguments are
inputs to each command.
llvm-svn: 242504
"-arm-use-movt=0".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11025
llvm-svn: 242368
We were still using the Unix response file tokenizer for all driver
modes. This was difficult to get right in the beginning because there is
a circular dependency. The Driver class also can't officially determine
its mode until it can see all possible --driver-mode= flags, and those
flags could come from the response file.
Now we use the Windows parsing algorithm if the program name looks like
clang-cl, or if the --driver-mode=cl flag is present on the main command
line.
Fixes PR23709.
Reviewers: hans
Differential Revision: http://reviews.llvm.org/D11229
llvm-svn: 242346
is true on MSYS bash although this requires: used to disable tests on MSYS bash.
Nevertheless, all tests requiring shell-preserves-root do pass except for
Driver/darwin-sdkroot.c. It will require a patch, either by disabling it on
Windows or by fixing shell-preserves-root to really be true only on MSYS
and making darwin-sdkroot.c its only user.
In any case, all other tests requiring shell-preserves-root do not really require
it so I'm replacing REQUIRES: shell-preserves-root with REQUIRES: shell in two
tests first.
llvm-svn: 242312
Rather than making -fexceptions a core option that enables C++ EH in
clang-cl, users can use the '-Xclang -fexceptions -Xclang
-fcxx-exceptions' flag set. We weren't going to expose -fexceptions in
clang-cl in the long run, so this way we don't add and then remove a
flag.
llvm-svn: 242176
NOTE: reverts r242077 to reinstate r242058, r242065, 242067
and includes fix for OS X test failures.
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
llvm-svn: 242085
The tests were failing on OS X.
Revert "[cuda] Driver changes to compile and stitch together host and device-side CUDA code."
Revert "Fixed regex to properly match '64' in the test case."
Revert "clang/test/Driver/cuda-options.cu REQUIRES clang-driver, at least."
llvm-svn: 242077
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
llvm-svn: 242058
We don't need any more bug reports from users telling us that MSVC-style
C++ exceptions are broken. Developers and adventurous users can still
test the existing functionality by passing along -fexceptions to either
clang or clang-cl.
llvm-svn: 241952
All of the ABIs we support are altivec style anyhow and so the option
doesn't make much sense with the modern ABIs. We could make this a more
noisy ignore, but it would break builds for projects that just pass
it along by default because of historical reasons.
llvm-svn: 241925
This patch corresponds to review:
http://reviews.llvm.org/D10972
Fix for the handling of dependent features that are enabled by default
on some CPU's (such as -mvsx, -mpower8-vector).
Also provides a number of new interfaces or fixes existing ones in
altivec.h.
Changed signatures to conform to ABI:
vector short vec_perm(vector signed short, vector signed short, vector unsigned char)
vector int vec_perm(vector signed int, vector signed int, vector unsigned char)
vector long long vec_perm(vector signed long long, vector signed long long, vector unsigned char)
vector signed char vec_sld(vector signed char, vector signed char, const int)
vector unsigned char vec_sld(vector unsigned char, vector unsigned char, const int)
vector bool char vec_sld(vector bool char, vector bool char, const int)
vector unsigned short vec_sld(vector unsigned short, vector unsigned short, const int)
vector signed short vec_sld(vector signed short, vector signed short, const int)
vector signed int vec_sld(vector signed int, vector signed int, const int)
vector unsigned int vec_sld(vector unsigned int, vector unsigned int, const int)
vector float vec_sld(vector float, vector float, const int)
vector signed char vec_splat(vector signed char, const int)
vector unsigned char vec_splat(vector unsigned char, const int)
vector bool char vec_splat(vector bool char, const int)
vector signed short vec_splat(vector signed short, const int)
vector unsigned short vec_splat(vector unsigned short, const int)
vector bool short vec_splat(vector bool short, const int)
vector pixel vec_splat(vector pixel, const int)
vector signed int vec_splat(vector signed int, const int)
vector unsigned int vec_splat(vector unsigned int, const int)
vector bool int vec_splat(vector bool int, const int)
vector float vec_splat(vector float, const int)
Added a VSX path to:
vector float vec_round(vector float)
Added interfaces:
vector signed char vec_eqv(vector signed char, vector signed char)
vector signed char vec_eqv(vector bool char, vector signed char)
vector signed char vec_eqv(vector signed char, vector bool char)
vector unsigned char vec_eqv(vector unsigned char, vector unsigned char)
vector unsigned char vec_eqv(vector bool char, vector unsigned char)
vector unsigned char vec_eqv(vector unsigned char, vector bool char)
vector signed short vec_eqv(vector signed short, vector signed short)
vector signed short vec_eqv(vector bool short, vector signed short)
vector signed short vec_eqv(vector signed short, vector bool short)
vector unsigned short vec_eqv(vector unsigned short, vector unsigned short)
vector unsigned short vec_eqv(vector bool short, vector unsigned short)
vector unsigned short vec_eqv(vector unsigned short, vector bool short)
vector signed int vec_eqv(vector signed int, vector signed int)
vector signed int vec_eqv(vector bool int, vector signed int)
vector signed int vec_eqv(vector signed int, vector bool int)
vector unsigned int vec_eqv(vector unsigned int, vector unsigned int)
vector unsigned int vec_eqv(vector bool int, vector unsigned int)
vector unsigned int vec_eqv(vector unsigned int, vector bool int)
vector signed long long vec_eqv(vector signed long long, vector signed long long)
vector signed long long vec_eqv(vector bool long long, vector signed long long)
vector signed long long vec_eqv(vector signed long long, vector bool long long)
vector unsigned long long vec_eqv(vector unsigned long long, vector unsigned long long)
vector unsigned long long vec_eqv(vector bool long long, vector unsigned long long)
vector unsigned long long vec_eqv(vector unsigned long long, vector bool long long)
vector float vec_eqv(vector float, vector float)
vector float vec_eqv(vector bool int, vector float)
vector float vec_eqv(vector float, vector bool int)
vector double vec_eqv(vector double, vector double)
vector double vec_eqv(vector bool long long, vector double)
vector double vec_eqv(vector double, vector bool long long)
vector bool long long vec_perm(vector bool long long, vector bool long long, vector unsigned char)
vector double vec_round(vector double)
vector double vec_splat(vector double, const int)
vector bool long long vec_splat(vector bool long long, const int)
vector signed long long vec_splat(vector signed long long, const int)
vector unsigned long long vec_splat(vector unsigned long long,
vector bool int vec_sld(vector bool int, vector bool int, const int)
vector bool short vec_sld(vector bool short, vector bool short, const int)
llvm-svn: 241904
This patch adds support for specifying where the profile is emitted in a
way similar to GCC. These flags are used to specify directories instead
of filenames. When -fprofile-generate=DIR is used, the compiler will
generate code to write to <DIR>/default.profraw.
The patch also adds a couple of extensions: LLVM_PROFILE_FILE can still be
used to override the directory and file name to use and -fprofile-use
accepts both directories and filenames.
To simplify the set of flags used in the backend, all the flags get
canonicalized to -fprofile-instr-{generate,use} when passed to the
backend. The decision to use a default name for the profile is done
in the driver.
llvm-svn: 241825
There are known issues, but the current implementation is good enough for
the check-cfi test suite.
Differential Revision: http://reviews.llvm.org/D11030
llvm-svn: 241728
For Mips direct-to-nacl, the goal is to be close to le32 front-end and
use Mips32EL backend. This patch defines new NaClMips32ELTargetInfo and
modifies it slightly to be close to le32. It also adds necessary parts,
inline with ARM and X86.
Differential Revision: http://reviews.llvm.org/D10739
llvm-svn: 241678
"-arm-long-calls".
This change allows using -mlong-calls/-mno-long-calls for LTO and enabling or
disabling long call on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D9414
llvm-svn: 241565
On Windows the user may invoke the linker directly, so we might not have an
opportunity to add runtime library flags to the linker command line. Instead,
instruct the code generator to embed linker directive in the object file
that cause the required runtime libraries to be linked.
We might also want to do something similar for ASan, but it seems to have
its own special complexities which may make this infeasible.
Differential Revision: http://reviews.llvm.org/D10862
llvm-svn: 241225
The main effect of this change is that /arch:IA32 will use i386 as the
CPU, while clang-cl will continue to default to pentium4 (aka SSE2 plus
the usual other features).
/arch:AVX and /arch:AVX2 will also now enable the other features
available in sandybridge and haswell respectively, which is consistent
with MSDN.
llvm-svn: 241077
Some of the the permissible ARM -mfpu options, which are supported in GCC,
are currently not present in llvm/clang.This patch adds the options:
'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16.
These are related to half-precision floating-point and single precision.
Reviewers: rengolin, ranjeet.singh
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10764
llvm-svn: 240929
Summary:
Namely, we must have proper C++ABI support in UBSan runtime. We don't
have a good way to check for that, so just assume that C++ABI support is
there whenever -fsanitize=vptr is supported (i.e. only on handful of
platforms).
Exact diagnostic is also tricky. It's not "cfi" that is unsupported,
just the diagnostic mode. So, I suggest to report that
"-fno-sanitize-trap=cfi-foobar" is incompatible with a given target
toolchain.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10751
llvm-svn: 240716
Summary:
For better or worse the OS X command line tools refer to the iOS simulator as iphonesimucator. We should provide an alias flag -miphonesimulator-version-min that matches a consistent pattern with the other tools.
This is in the interest of making it easier for people to write platform-agnostic darwin build scripts.
Reviewers: bob.wilson, bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10743
llvm-svn: 240686
Summary:
This is the Clang part of the PPC64 memory sanitizer implementation in
D10648.
Reviewers: kcc, eugenis, willschm, wschmidt, samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10650
llvm-svn: 240628
This re-commits r226005 with a tweak. The origin attempt failed because
Darwin bot sets up SDKROOT and clang can deduce SDK version from them
after this patch. That broke many driver tests due to the change of
deployment target version. Now the tests should not complain after
r240574.
llvm-svn: 240619
Summary:
Remove some of dangerous environmental variables from clang/Driver tests.
Driver tests should not rely on preset value of these variables and may
actually fail because of them.
They cannot be removed in test/lit.cfg because we still need to support
relocatable SDKs and other overwrite for other clang tests.
Reviewers: bogner
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D7135
llvm-svn: 240574
Classes in Tools.h inherit ultimately from Tool, which is a noun,
but subclasses of Tool were named for their operation, such as "Compile",
wherein the constructor call "Compile(args...)" could be misconstrued
as actually causing a compile to happen.
Likewise various other methods were not harmonious with their effect,
in that "BuildLinker()" returned a "new namespace::Link(...)"
instead of a "new namespace::Linker(...)" which it now does.
Exceptions: Clang and ClangAs are un-renamed. Those are their rightful names.
And there is no particulary great way to name the "Lipo-er" and a few others.
Differential Revision: http://reviews.llvm.org/D10595
llvm-svn: 240455
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.
llvm-svn: 240179
Summary:
This is unfortunate, but would let us land http://reviews.llvm.org/D10467,
that makes ToolChains responsible for computing the set of sanitizers
they support.
Unfortunately, Darwin ToolChains doesn't know about actual OS they
target until ToolChain::TranslateArgs() is called. In particular, it
means we won't be able to construct SanitizerArgs for these ToolChains
before that.
This change removes SanitizerArgs::needsLTO() method, so that now
ToolChain::IsUsingLTO(), which is called very early, doesn't need
SanitizerArgs to implement this method.
Docs and test cases are updated accordingly. See
https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we
start all these.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10560
llvm-svn: 240170
This change passes through C and assembler jobs to Movidius tools by
constructing commands which are the same as ones produces by the examples
in the SDK. But rather than reference MV_TOOLS_DIR to find tools,
we will assume that binaries are installed wherever the Driver would
find its native tools. Similarly, this change assumes that -I options
will "just work" based on where SDK headers get installed, rather than
baking into the Driver some magic paths.
Differential Revision: http://reviews.llvm.org/D10440
llvm-svn: 240134
This patch adds initial support for the -fsanitize=kernel-address flag to Clang.
Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported.
Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux.
To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used.
llvm-svn: 240131
This flag controls whether a given sanitizer traps upon detecting
an error. It currently only supports UBSan. The existing flag
-fsanitize-undefined-trap-on-error has been made an alias of
-fsanitize-trap=undefined.
This change also cleans up some awkward behavior around the combination
of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we
would reject command lines containing the combination of these two flags,
as -fsanitize=vptr is not compatible with trapping. This required the
creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr
(and -fsanitize=function, but this seems like an oversight).
Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap,
and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr
as an "unsupported" flag, which means that we error out if the flag is
specified explicitly, but implicitly disable it if the flag was implied
by -fsanitize=undefined.
Differential Revision: http://reviews.llvm.org/D10464
llvm-svn: 240105
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -march option for the AArch64 target.
llvm-svn: 240019
Summary:
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support (i.e.
set from -fsanitize=undefined-trap).
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539)
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith
Differential Revision: http://reviews.llvm.org/D10467
llvm-svn: 239953
Summary:
If the driver is only given -msoft-float/-mfloat-abi=soft or -msingle-float,
we should refrain from propagating -mfpxx, unless it was explicitly given on the
command line.
Reviewers: atanasyan, dsanders
Reviewed By: atanasyan, dsanders
Subscribers: cfe-commits, mpf
Differential Revision: http://reviews.llvm.org/D10387
llvm-svn: 239818
This patch adds the -fsanitize=safe-stack command line argument for clang,
which enables the Safe Stack protection (see http://reviews.llvm.org/D6094
for the detailed description of the Safe Stack).
This patch is our implementation of the safe stack on top of Clang. The
patches make the following changes:
- Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang
to control safe stack usage (the safe stack is disabled by default).
- Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be
used to disable the safe stack for individual functions even when enabled
globally.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6095
llvm-svn: 239762
LLVM does not and has not ever supported a soft-float ABI mode on
Sparc, so don't pretend that it does.
Also switch the default from "soft-float" -- which was actually
hard-float because soft-float is unimplemented -- to hard-float.
Differential Revision: http://reviews.llvm.org/D10457
llvm-svn: 239755
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option for the AArch64 target.
llvm-svn: 239619
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -march option for ARM.
llvm-svn: 239527
Summary: We already pass these to the IAS, but not to GAS.
Reviewers: dsanders, atanasyan
Reviewed By: atanasyan
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10358
llvm-svn: 239525
This matches the cl.exe behavior (tested with 18.00.31101). In order to
specify an output file for /P, use the /Fi option instead.
Differential Revision: http://reviews.llvm.org/D10313
llvm-svn: 239393
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
llvm-svn: 239388
Encoding the version into the triple will allow us to communicate to
LLVM what functions it can expect to depend upon in the implementation.
llvm-svn: 239273
Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9
layout for sparc (32bit), sparc (32bit) with lib64 multilib, and
sparc64.
The test cases added here also cover r239047, which fixed the linker
paths.
llvm-svn: 239154
The main effect of this is to fix anomalies where certain -mfpu options didn't
disable everything that they should causing strange behaviour when combined
with -mcpu or -march values that themselves enabled fpu subtarget features,
e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as
-mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled.
Invalid -mfpu options now also give an error, which is consistent with the
handling of the .fpu directive.
Differential Revision: http://reviews.llvm.org/D10239
llvm-svn: 239152
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
llvm-svn: 239059
If we crash while handling headers, the crash report mechanism
currently tries to make a string out of a null pointer when it tries
to make up a file extension.
Map *-header input types to reasonable extensions to avoid this.
llvm-svn: 238994
getCanonicalArchName can return an empty string for an architecture
that is well-formed but meaningless. Use parseArch to determine if
it's actually valid or not.
Differential Revision: http://reviews.llvm.org/D10120
llvm-svn: 238553
works well for folks.
This isn't terribly clean (sadly) but after chatting with both Eric and
Richard, nothing cleaner really emerged. The clean way of doing this is
a *lot* of work for extremely little benefit here.
llvm-svn: 238500
This isn't an actual revert of r237769, it just restores the behavior of
the Clang driver prior to it while completely re-implementing how that
behavior works.
This also re-does the work of making the default OpenMP runtime
selectable at CMake (or configure) time to work in the way all of our
other such hooks do (config.h, configure and cmake hooks, etc.).
I've re-implemented how we manage the '-fopenmp' flagset in an important
way. Now, the "default" hook just makes '-fopenmp' equivalent to
'-fopenmp=<default>' rather than a separate special beast. Also, there
is an '-fno-openmp' flag which does the obvious thing. Also, the code is
shared between all the places to select a known OpenMP runtime and act
on it.
Finally, and most significantly, I've taught the driver to inspect the
selected runtime when choosing whether to propagate the '-fopenmp' flag
to the frontend in the CC1 commandline. Without this, it isn't possible
to use Clang with libgomp, even if you were happy with the serial,
boring way in which it worked previously (ignoring all #pragmas but
linking in the library to satisfy direct calls into the runtime).
While I'm here, I've gone ahead and sketched out a path for the future
name of LLVM's OpenMP runtime (libomp) and the legacy support for its
current name (libiomp5) in what seems a more reasonable way.
To re-enable LLVM's OpenMP runtime (which I think should wait until the
normal getting started instructions are a reasonable way for falks to
check out, build, and install Clang with the runtime) all that needs to
change is the default string in the CMakeLists.txt and configure.ac
file. No code changes necessary.
I also added a test for the driver's behavior around OpenMP since it was
*completely missing* previously. Makes it unsurprising that we got it
wrong.
llvm-svn: 238389
Using the target cpu to determine some behaviour is sprinkled in
several places in the driver, but in almost all the information that
is needed can be found in the triple. Restructure things so that the
triple is used, and the cpu is only used if the exact cpu name is
needed.
Also add a check that the -mcpu argument is valid, and correct the
-march argument checking so that it handles -march=native correctly. I
would have liked to move these checks into the computation of the
triple, but the triple is calculated several times in several places
and that would lead to multiple error messages for the same thing.
Differential Revision: http://reviews.llvm.org/D9879
llvm-svn: 237894
Don't print unused-argument warning for sanitizer-specific feature flag
if this sanitizer was eanbled, and later disabled in the command line.
For example, now:
clang -fsanitize=address -fsanitize-coverage=bb -fno-sanitize=address a.cc
doesn't print warning, but
clang -fsanitize-coverage=bb
does. Same holds for -fsanitize-address-field-padding= and
-fsanitize-memory-track-origins= flags.
Fixes PR23604.
llvm-svn: 237870
The MachO toolchain has an isTargetIOSBased method, but it isn't
virtual so it isn't very meaningful to call it. After thinking about
this, I guess that putting this logic in the MachO class is a bit of a
layering violation anyway. Do this more like how we handle
AddLinkRuntimeLibArgs instead.
llvm-svn: 237095
Compiler-rt's Profiling library isn't part of the stdlib, so -nostdlib
shouldn't prevent it from being linked. This makes Darwin behave like
other toolchains, and link in the profile runtime irrespective of
-nostdlib, since the resulting program can't be run unless you link
this.
I've also added a test to show that other toolchains already behave
like this.
llvm-svn: 237074
After mailing list discussion on 11-13 March we would prefer to stick to a
single spelling of the long option.
This reverts commit 30035fe1a7c759c89ee62eb46efce6b3790fcc08.
llvm-svn: 237003
This is a starting point for using the TargetParser in Clang, in a simple
enough part of the code that can be used without disrupting the crazy
platform support that we need to be compatible with other toolchains.
Also adding a few FIXME on obvious places that need replacing, but those
cases will indeed break a few of the platform assumptions, as arch/cpu names
change multiple times in the driver.
Finally, I'm changing the "neon-vfpv3" behaviour to match standard NEON, since
-mfpu=neon implies vfpv3 by default in both Clang and LLVM. That option
string is still supported as an alias to "neon".
llvm-svn: 236901
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
Patch by Gabor Ballabas.
llvm-svn: 236859
llvm::Triple::getARMCPUForArch now returns nullptr for invalid -march
values, instead of silently translating it to arm7tdmi. Use this to
give an error message, which is consistent with how gcc behaves.
Differential Revision: http://reviews.llvm.org/D9602
llvm-svn: 236846
Summary:
Possible coverage levels are:
* -fsanitize-coverage=func - function-level coverage
* -fsanitize-coverage=bb - basic-block-level coverage
* -fsanitize-coverage=edge - edge-level coverage
Extra features are:
* -fsanitize-coverage=indirect-calls - coverage for indirect calls
* -fsanitize-coverage=trace-bb - tracing for basic blocks
* -fsanitize-coverage=trace-cmp - tracing for cmp instructions
* -fsanitize-coverage=8bit-counters - frequency counters
Levels and features can be combined in comma-separated list, and
can be disabled by subsequent -fno-sanitize-coverage= flags, e.g.:
-fsanitize-coverage=bb,trace-bb,8bit-counters -fno-sanitize-coverage=trace-bb
is equivalient to:
-fsanitize-coverage=bb,8bit-counters
Original semantics of -fsanitize-coverage flag is preserved:
* -fsanitize-coverage=0 disables the coverage
* -fsanitize-coverage=1 is a synonym for -fsanitize-coverage=func
* -fsanitize-coverage=2 is a synonym for -fsanitize-coverage=bb
* -fsanitize-coverage=3 is a synonym for -fsanitize-coverage=edge
* -fsanitize-coverage=4 is a synonym for -fsanitize-coverage=edge,indirect-calls
Driver tries to diagnose invalid flag usage, in particular:
* At most one level (func,bb,edge) must be specified.
* "trace-bb" and "8bit-counters" features require some level to be specified.
See test case for more examples.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9577
llvm-svn: 236790
Summary:
The next step is to add user-friendly control over these options
to driver via -fsanitize-coverage= option.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9545
llvm-svn: 236756
This patch adds support for the z13 architecture type. For compatibility
with GCC, a pair of options -mvx / -mno-vx can be used to selectively
enable/disable use of the vector facility.
When the vector facility is present, we default to the new vector ABI.
This is characterized by two major differences:
- Vector types are passed/returned in vector registers
(except for unnamed arguments of a variable-argument list function).
- Vector types are at most 8-byte aligned.
The reason for the choice of 8-byte vector alignment is that the hardware
is able to efficiently load vectors at 8-byte alignment, and the ABI only
guarantees 8-byte alignment of the stack pointer, so requiring any higher
alignment for vectors would require dynamic stack re-alignment code.
However, for compatibility with old code that may use vector types, when
*not* using the vector facility, the old alignment rules (vector types
are naturally aligned) remain in use.
These alignment rules are not only implemented at the C language level,
but also at the LLVM IR level. This is done by selecting a different
DataLayout string depending on whether the vector ABI is in effect or not.
Based on a patch by Richard Sandiford.
llvm-svn: 236531
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.
llvm-svn: 236121
Embed UBSan runtime into TSan and MSan runtimes in the same as we do
in ASan. Extend UBSan test suite to also run tests for these
combinations.
llvm-svn: 235953
For now tsan_cxx and msan_cxx contain only operator new/delete
replacements. In the future, when we add support for running UBSan+TSan
and UBSan+MSan, they will also contain bits ubsan_cxx runtime.
llvm-svn: 235924
Before this patch, passing a non-existent absolute path to clang-cl would cause
stat'ing of impossible paths. For example, `clang-cl -c d:\adsfasdf.txt` would
cause a stat of
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIBd:\asdfadsf.cc
llvm-svn: 235787
Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc).
Note that despite its generic name, it *doesn't* do the right thing when
-emit-llvm (LLVM assembly) yet. I'll hook that up soon.
This doesn't really change the behaviour of the driver. The default is
still to preserve use-lists for `clang -emit-llvm` and `clang
-save-temps`, and nothing else. But it stops relying on global state
(and also is a nicer interface for hackers using `clang -cc1`).
llvm-svn: 234962
Change `clang` to set `-preserve-bc-uselistorder` for the driver options
`-emit-llvm` and `-save-temps`. The former is useful for reproducing
results from `clang` in `opt` or `llc`, while the latter prevents
`-save-temps` from affecting the output. This is part of PR5680.
`-preserve-bc-uselistorder=true` is currently on by default, but a
follow-up commit in LLVM will reverse it.
llvm-svn: 234920
This patch generates a warning for invalid combination of '-mnan' and
'-march' options, it properly sets NaN encoding for a given '-march',
and it passes a proper NaN encoding to the assembler.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D8170
llvm-svn: 234882
Follow-up to r234666. With this, the -m[no-]global-merge options
have the expected behavior. Previously, -mglobal-merge was ignored,
and there was no way of enabling the optimization.
llvm-svn: 234668
Summary:
tools::arm::getARMFloatABI() was falling back to guessing soft-float because
it wasn't seeing the GNUEABIHF environment from ComputeEffectivClangTriple
when it was called from gnutools::Assemble::ConstructJob.
Fix by using the effective clang triple in gnutools::Assemble, which now
matches the -triple flag used by cc1 and ClangAs jobs.
Reviewers: jvoung
Subscribers: rengolin, jfb, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D8902
llvm-svn: 234661
We don't actually need a real Mac sysroot to make the test pass, just a
linker. This makes the test pass in environments where no ld is on
PATH.
llvm-svn: 234533
The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
generation in IR.
Note that this change does not actually enable the optimization for
any target. The reassociation optimization that this flag specifies
was implemented by http://reviews.llvm.org/D6334 :
http://llvm.org/viewvc/llvm-project?view=revision&revision=222510
Because the optimization is done in the backend rather than IR,
the backend must be modified to understand instruction-level
fast-math-flags or a new function-level attribute must be created.
Also note that -freciprocal-math is independent of any target-specific
usage of reciprocal estimate hardware instructions. That requires
its own flag ('-mrecip').
https://llvm.org/bugs/show_bug.cgi?id=20912
llvm-svn: 234493
Adds ARM Cortex-R4 and R4F support and tests in Clang. Though Cortex-R4
support was present, the support for hwdiv in thumb-mode was not defined
or tested properly. This has also been added.
llvm-svn: 234488
This hooks up the /fp options as aliases for -f[no-]fast-math and
-f[no]-trapping-math. It probably doesn't match cl.exe's behaviour
completely (e.g. LLVM is currently never as precise as /fp:precise),
but it's close enough.
Differential revision: http://reviews.llvm.org/D8909
llvm-svn: 234449
Currently if you use -mmacosx-version-min or -mios-version-min without
specifying a version number, clang silently sets the minimum version to
"0.0.0". This is almost certainly not what was intended, so it is better
to report it as an error. rdar://problem/20433945
llvm-svn: 234270
Original message:
Don't use unique section names by default if using the integrated as.
This saves some IO and ccache space by not creating long section names. It
should work with every ELF linker.
llvm-svn: 234143
This reverts commit r233398, bringing back 233393 now that LLVM is fixed.
Original message:
Don't use unique section names by default if using the integrated as.
This saves some IO and ccache space by not creating long section names. It
should work with every ELF linker.
llvm-svn: 234101
This uses the same class metadata currently used for virtual call and
cast checks.
The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr
flag has been renamed -fsanitize=cfi-vcall.
Differential Revision: http://reviews.llvm.org/D8756
llvm-svn: 233874
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change doesn't
modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8645
llvm-svn: 233860
The zEC12 provides the transactional-execution facility. This is exposed
to users via a set of builtin routines on other compilers. This patch
adds clang support to enable those builtins. In partciular, the patch:
- enables the transactional-execution feature by default on zEC12
- allows to override presence of that feature via the -mhtm/-mno-htm options
- adds a predefined macro __HTM__ if the feature is enabled
- adds support for the transactional-execution GCC builtins
- adds Sema checking to verify the __builtin_tabort abort code
- adds the s390intrin.h header file (for GCC compatibility)
- adds s390 sections to the htmintrin.h and htmxlintrin.h header files
Since this is first use of target-specific intrinsics on the platform,
the patch creates the include/clang/Basic/BuiltinsSystemZ.def file and
hooks it up in TargetBuiltins.h and lib/Basic/Targets.cpp.
An associated LLVM patch adds the required LLVM IR intrinsics.
For reference, the transactional-execution instructions are documented
in the z/Architecture Principles of Operation for the zEC12:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/DZ9ZR009.pdf
The associated builtins are documented in the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc/S_002f390-System-z-Built-in-Functions.html
The htmxlintrin.h intrinsics provided for compatibility with the IBM XL
compiler are documented in the "z/OS XL C/C++ Programming Guide".
llvm-svn: 233804
Add Tool and ToolChain support for clang to target the NaCl OS using the NaCl
SDK for x86-32, x86-64 and ARM.
Includes nacltools::Assemble and Link which are derived from gnutools. They
are similar to Linux but different enought that they warrant their own class.
Also includes a NaCl_TC in ToolChains derived from Generic_ELF with library
and include paths suitable for an SDK and independent of the system tools.
Differential Revision: http://reviews.llvm.org/D8590
llvm-svn: 233594
Unlike most of the other platforms supported by Clang, CloudABI only
supports static linkage, for the reason that global filesystem access is
prohibited. Functions provided by dlfcn.h are not present. As we know
that applications will not try to do any symbol lookups at run-time, we
can garbage collect unused code quite aggressively. Because of this, it
makes sense to enable -ffunction-sections and -fdata-sections by
default.
Object files will be a bit larger than usual, but the resulting binary
will not be affected, as the sections are merged again. However, when
--gc-sections is used, the linker is able to remove unused code far more
more aggressively. It also has the advantage that transitive library
dependencies only need to be provided to the linker in case that
functionality is actually used.
Differential Revision: http://reviews.llvm.org/D8635
Reviewed by: echristo
llvm-svn: 233299
Now that CloudABI's target information and header search logic for Clang
has been submitted, the only thing that remains to be done is adding
support for CloudABI's linker.
CloudABI uses Binutils ld, although there is some work to use lld
instead. This means that this code is largely based on what we use on
FreeBSD. There are some exceptions, however:
- Only static linking is performed. CloudABI does not support any
dynamically linked executables.
- CloudABI uses compiler-rt, libc++ and libc++abi unconditionally. Link
in these libraries instead of using libgcc_s, libstdc++, etc.
- We must ensure that the .eh_frame_hdr is present to make C++
exceptions work properly.
Differential Revision: http://reviews.llvm.org/D8250
llvm-svn: 233269
they enable/disable.
This fixes two things:
a) sse4 isn't actually a target feature, don't treat it as one.
b) we weren't correctly disabling sse4.1 when we'd pass -mno-sse4
after enabling it, thus passing preprocessor directives and
(soon) passing the function attribute as well when we shouldn't.
llvm-svn: 233223
Summary:
On my system, clang tries to invoke /path/to/arm-linux-androideabi-ld
as the linker for Android, and the regex inside the test file considers
this as unacceptable.
Reviewers: samsonov
Subscribers: tberghammer, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D8598
llvm-svn: 233211
Summary:
UBSan is now used in the same way as ASan, and is supported on
OSX and on iOS simulator. At the moment ASan and UBSan can't be used
together due to PR21112, but I hope to resolve it soon by
embedding UBSan into ASan.
Test Plan: regression test suite.
Reviewers: zaks.anna, kubabrecka
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8471
llvm-svn: 233035
Get rid of "libclang_rt.san" library that used to contain
sanitizer_common pieces required by UBSan if it's used in a standalone
mode. Instead, build two variants of UBSan runtime: "ubsan" and
"ubsan_standalone" (same for "ubsan_cxx" and "ubsan_standalone_cxx").
Later "ubsan" and "ubsan_cxx" libraries will go away, as they will
embedded it into corresponding ASan runtimes.
llvm-svn: 233010
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
N.B. CodeGen support is still ongoing.
llvm-svn: 232906
Summary:
We were claiming the -f*exceptions arguments when looking for the
RTTIMode. This makes us not warn about unused arguments if compiling a C
file with -fcxx-exceptions.
This patch fixes it by not claiming the exception-related arguments at
that point.
Reviewers: rsmith, samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8507
llvm-svn: 232860
We are not able to make a reliable solution for using UBSan together
with other sanitizers with runtime support (and sanitizer_common).
Instead, we want to follow the path used for LSan: have a "standalone"
UBSan tool, and plug-in UBSan that would be explicitly embedded into
specific sanitizers (in short term, it will be only ASan).
llvm-svn: 232829
Summary: As discussed in D8097, we should provide corresponding linking flags when 'fveclib' is specified.
Reviewers: hfinkel
Differential Revision: http://reviews.llvm.org/D8362
llvm-svn: 232556
ARMv6K is another layer between ARMV6 and ARMV6T2. This is the Clang
side of the changes.
ARMV6 family LLVM implementation.
+-------------------------------------+
| ARMV6 |
+----------------+--------------------+
| ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors
+----------------+--------------------+ have support for hint instructions
| ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can
+-------------------------------------+ be either real or default to NOP.
| ARMV7 (arm,thumb,thumb2) | The two processors also use
+-------------------------------------+ different encoding for them.
Patch by Vinicius Tinti.
llvm-svn: 232469
This scheme checks that pointer and lvalue casts are made to an object of
the correct dynamic type; that is, the dynamic type of the object must be
a derived class of the pointee type of the cast. The checks are currently
only introduced where the class being casted to is a polymorphic class.
Differential Revision: http://reviews.llvm.org/D8312
llvm-svn: 232241
For crashes with a VFS (ie, with modules), the -isysroot flag is often
necessary to reproduce the crash. This is especially true if some
modules need to be rebuilt, since without the sysroot they'll try to
read headers that are outside of the VFS.
I find it likely that we should keep some of the other -i flags in
this case as well, but I haven't seen that come up in practice yet so
it seems better to be conservative.
llvm-svn: 231997
When a crash report script doesn't work for a reproduction on your
machine for one reason or another, it can be really tricky to figure
out why not. The compiler version that crashed and the original
command line before stripping flags are very helpful when this comes
up.
llvm-svn: 231989
Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.
llvm-svn: 231960
Using clang as a cross-compiler with the 'target' option could be confusing
for those inexperienced in the realm of cross compiling.
This patch would allow the use of all these four variants of the target option:
-target <triple>
--target <triple>
-target=<triple>
--target=<triple>
Patch by Gabor Ballabas.
llvm-svn: 231787
This is a recommit of r231150, reverted in r231409. Turns out
that -fsanitize=shift-base check implementation only works if the
shift exponent is valid, otherwise it contains undefined behavior
itself.
Make sure we check that exponent is valid before we proceed to
check the base. Make sure that we actually report invalid values
of base or exponent if -fsanitize=shift-base or
-fsanitize=shift-exponent is specified, respectively.
llvm-svn: 231711
simplicity in build systems, silence '-stdlib=libc++' when linking. Even
if we're not linking C++ code per-se, we may be passing this flag so
that when we are linking C++ code we pick up the desired standard
library. While most build systems already provide separate C and C++
compile flags, many conflate link flags. Sadly, CMake is among them
causing this warning in a libc++ selfhost.
llvm-svn: 231559
It's not that easy. If we're only checking -fsanitize=shift-base we
still need to verify that exponent has sane value, otherwise
UBSan-inserted checks for base will contain undefined behavior
themselves.
llvm-svn: 231409
Summary:
When using the IAS from clang, the 'target-abi' option gets passed to cc1as, but cc1as doesn't know about it and gives an "unknown argument" error.
This is fixed by adding the 'CC1AsOption' flag to the 'target-abi' option in CC1Options.td.
Reviewers: atanasyan, echristo, dsanders
Reviewed By: dsanders
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7903
llvm-svn: 231244
-fsanitize=shift is now a group that includes both these checks, so
exisiting users should not be affected.
This change introduces two new UBSan kinds that sanitize only left-hand
side and right-hand side of shift operation. In practice, invalid
exponent value (negative or too large) tends to cause more portability
problems, including inconsistencies between different compilers, crashes
and inadequeate results on non-x86 architectures etc. That is,
-fsanitize=shift-exponent failures should generally be addressed first.
As a bonus, this change simplifies CodeGen implementation for emitting left
shift (separate checks for base and exponent are now merged by the
existing generic logic in EmitCheck()), and LLVM IR for these checks
(the number of basic blocks is reduced).
llvm-svn: 231150
Summary:
There is no -no-pie flag that can override this, so making it default
to being on for Android means it is no longer possible to create
non-PIE executables on Android. While current versions of Android
support (and the most recent requires) PIE, ICS and earlier versions
of Android cannot run PIE executables, so this needs to be optional.
Reviewers: srhines
Reviewed By: srhines
Subscribers: thakis, volkalexey, cfe-commits
Differential Revision: http://reviews.llvm.org/D8015
llvm-svn: 231091
Modules and Tooling tests in particular tend to want to change the cwd,
so we were missing test coverage in this area on Windows. It should now
be easier to write such portable tests.
llvm-svn: 231029
Change -fsanitize-memory-track-origins to be equivalent to
-fsanitize-memory-track-origins=2.
Track-origins=2 provides a lot more detailed reports at the cost of
some additional slowdown (ranging from none to, sometimes, 3x; ~3% average on
SPEC2006).
llvm-svn: 230644
There is no supported toolchain which provides headers / libs / object
files specific to the mips32r[3|5] and mips64r[3|5] ISA. So select "r2"
specific folders when they are available.
http://reviews.llvm.org/D7879
llvm-svn: 230611
While it's true that we don't create the PDB as requested on the command
line, this is a well-documented limitation. Warning about it doesn't
help people using legacy build systems with clang-cl, and it makes the
clang-cl self-host very noisy.
llvm-svn: 230527
VS 2013 is the minimum supported version, so it's reasonable for Clang
to simulate this by default. This also simplifies the clang-cl
self-host, since we have the 18.00 version check.
llvm-svn: 230243
The patch teaches the clang's driver to understand new MIPS ISA names,
pass appropriate options to the assembler, defines corresponding macros etc
http://reviews.llvm.org/D7737
llvm-svn: 230092
This patch introduces the -fsanitize=cfi-vptr flag, which enables a control
flow integrity scheme that checks that virtual calls take place using a vptr of
the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst
file.
It also introduces the -fsanitize=cfi flag, which is currently a synonym for
-fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented
in Clang.
Differential Revision: http://reviews.llvm.org/D7424
llvm-svn: 230055
For now -funique-section-names is the default, so no change in default behavior.
The total .o size in a build of llvm and clang goes from 241687775 to 230649031
bytes if -fno-unique-section-names is used.
llvm-svn: 230031
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
Add some of the missing M and R class Cortex CPUs, namely:
Cortex-M0+ (called Cortex-M0plus for GCC compatibility)
Cortex-M1
SC000
SC300
Cortex-R5
llvm-svn: 229661
This is typically used to suppress warnings about calling snprintf and
other "deprecated" POSIX functions. Accepting this flag helps avoid tons
of useless warnings when trying out clang-cl on a new project.
Patch by Scott Graham!
llvm-svn: 229583
The /volatile:ms semantics turn volatile loads and stores into atomic
acquire and release operations. This distinction is important because
volatile memory operations do not form a happens-before relationship
with non-atomic memory. This means that a volatile store is not
sufficient for implementing a mutex unlock routine.
Differential Revision: http://reviews.llvm.org/D7580
llvm-svn: 229082
If the linker is gcc (the default for Generic_ELF toolchains), we end up
passing most of the arguments to the linker.
Some tests were failing to account for this in their usage of *-NOT: lines
and would fail if compiled with
-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-unknown
llvm-svn: 228902
Somehow a check for aarch64 was added to the Darwin toolchain's
isKernelStatic function as part of the initial commit for Apple's
arm64 target (r205100). That check was not in any of Apple's internal
code and no one here knows where it came from. It has been harmless
because "-static" does not change much, if anything, for arm64 iOS code,
but it makes no sense to keep this check.
llvm-svn: 228673
Summary:
-iframework option is used to specified System framework path so the
path specified should be passed to linker as -F option
rdar://problem/18234544
Reviewers: bob.wilson
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7106
llvm-svn: 228413
This patch adds an extra test case to clang-exception-flags.cpp.
No functional change intended.
Patch by Wolfgang Pieb!
Reviewers: filcab, alexr
Differential Revision: http://reviews.llvm.org/D7298
llvm-svn: 228394
Summary:
This test was failing if LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 due to
its behavior for exceptions.
Force an --unknown triple for the default case.
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7422
llvm-svn: 228337
After r228258, Clang started emitting C++ EH IR that LLVM wasn't ready
to deal with, even when exceptions were disabled with /EHs-. This time,
make /EHs- turn off -fexceptions while still emitting exceptional
constructs in functions using __try. Since Sema rejects C++ exception
handling constructs before CodeGen, landingpads should only appear in
such functions as the result of a __try.
llvm-svn: 228329
In r227480, Ulrich Weigand introduced a workaround for a linker
optimization bug that can create mis-optimized code for accesses to
general-dynamic or local-dynamic TLS variables. The linker
optimization bug only occurred for Clang/LLVM because of some
inefficient code being generated for these TLS accesses. I have
recently corrected LLVM to produce the efficient code sequence
expected by the linkers, so this workaround is no longer needed.
Therefore this patch reverts r227480.
I've tested that the previous bootstrap failure no longer occurs with
the workaround reverted.
llvm-svn: 228253
Summary:
Now that the darwin-version tests in Driver and Frontend are
testing different parts of the version encoding instead of doing
duplicated work
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D7134
llvm-svn: 228159
Summary:
Allow user to provide multiple blacklists by passing several
-fsanitize-blacklist= options. These options now don't override
default blacklist from Clang resource directory, which is always
applied (which fixes PR22431).
-fno-sanitize-blacklist option now disables all blacklists that
were specified earlier in the command line (including the default
one).
This change depends on http://reviews.llvm.org/D7367.
Test Plan: regression test suite
Reviewers: timurrrr
Subscribers: cfe-commits, kcc, pcc
Differential Revision: http://reviews.llvm.org/D7368
llvm-svn: 228156
Appends the username to the first component (after the temp dir) of the
module cache path. If the username contains a character that shouldn't
go into a path (for now conservatively allow [a-zA-Z0-9_]), we fallback
to the user id.
llvm-svn: 228013
-save-temps=cwd is equivalent to -save-temps
-save-temps=obj saves temporary file in the same directory as output
This helps to avoid clobbering of temp files in case of parallel
compilation with -save-temps of the files that have the same name
but located in different directories.
Patch by Artem Belevich
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D7304
llvm-svn: 227886
Summary:
The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling
exceptions.
This commit makes clang add the -fno-rtti by default on the PS4, unless
-frtti was passed in.
It also diagnoses misuses for the PS4:
- Exceptions need rtti. Warn and enable rtti if no rtti flag was passed,
error if -fno-rtti was passed.
I also added a more general warning for when -fno-rtti is the default
(currently it's only on the PS4) and the vptr sanitizer is on.
Fixed a few tests, due to different flag order when passing cc1 arguments.
Reviewers: chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7250
llvm-svn: 227518
Work around a bug in GNU ld (and gold) linker versions up to 2.25
that may mis-optimize code generated by this version of clang/LLVM
to access general-dynamic or local-dynamic TLS variables.
Bug is fixed here:
https://sourceware.org/ml/binutils/2015-01/msg00318.html
llvm-svn: 227480
Those used the old Big Endian support on ARM and don't need flags.
Refactor the logic in a separate common function, which also looks at
-march. Add corresponding logic for the Linux toolchain.
llvm-svn: 227393
Summary:
This was already done for the sanitizers, but it needs to be done for
the profile and builtin libs as well.
Reviewers: srhines, timmurray, eugenis, samsonov
Reviewed By: samsonov
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D7187
llvm-svn: 227392
Without this patch, this test was accidentally testing that
CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING
were set to a particular set of values.
The test was also getting pretty hairy since it was attempting to craft
a regular expression that covered "all" possible combinations of
settings for these configure-time constants.
Clean it up by directly capturing the resource directory in a FileCheck
variable.
llvm-svn: 227310
This patch allows clang to have llvm reserve the x18
platform register on AArch64. FreeBSD will use this in the kernel for
per-cpu data but has no need to reserve this register in userland so
will need this flag to reserve it.
This uses llvm r226664 to allow this register to be reserved.
Patch by Andrew Turner.
llvm-svn: 227062
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
The PPC backend will now assume that PPC64 ELFv1 function descriptors are
invariant. This must be true for well-defined C/C++ code, but I'm providing an
option to disable this assumption in case someone's JIT-engine needs it.
llvm-svn: 226209
Summary:
This is a more robust way of figuring out implicit deployment target
from isysroot. It also handles iphone simulator target.
Reviewers: bob.wilson, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, cfe-commits
Differential Revision: http://reviews.llvm.org/D6939
llvm-svn: 226005
Gabor Ballabas