-fms-compatibility-version was defaulting to 18 (VS 2013), which is a pain if your environment is pointing to version 19 (VS 2015) libraries.
If cl.exe can be found, this patch uses its version number as the default instead. It re-uses the existing code to find the Visual Studio binaries folder and WinAPI methods to check its version. You can still explicitly specify a compatibility version on the command line. If you don't have cl.exe, this should be a no-op and you'll get the old default of 18.
This affected the tests, which assumed that if you didn't specific a version, that it would default to 18, but this won't be true for all machines. So a couple test cases had to be eliminated and a couple others had to be tweaked to allow for various outputs.
Addresses: https://llvm.org/bugs/show_bug.cgi?id=27215
Differential Revision: http://reviews.llvm.org/D20136
llvm-svn: 269515
Summary:
This option allows the user to control how much of the file name is
emitted by UBSan. Tuning this option allows one to save space in the
resulting binary, which is helpful for restricted execution
environments.
With a positive N, UBSan skips the first N path components.
With a negative N, UBSan only keeps the last N path components.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19666
llvm-svn: 269309
Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file. Using -fembed-bitcode-marker will only introduce a
marker in both sections.
Depends on D17390
Reviewers: rsmith
Subscribers: yaron.keren, vsk, cfe-commits
Differential Revision: http://reviews.llvm.org/D17392
llvm-svn: 269202
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ]
clang support on Haiku is lagging a bit, and missing on x86_64.
This patch updates support for x86 and add support for x86_64. It should
apply directly to trunk and it's harmless in the sense that it only
affects Haiku.
Reviewers: rnk, rsmith
Patch by Jérôme Duval
Differential Revision: http://reviews.llvm.org/D16797
llvm-svn: 269201
This patch corresponds to review:
http://reviews.llvm.org/D19684
It simply adds the handling for the option and the corresponding macros.
llvm-svn: 268951
- Don't consider "/etc/lsb-release" to be Ubuntu only.
- Detect SL, too.
- Only add "--no-add-needed" for RHEL7 (or Fedora), not for RHEL6
(that's what the compilers shipped with RHEL do).
- removed RHEL4 which is now four years past EOL and certainly incapable
of building or running any recent version of llvm/clang.
llvm-svn: 268914
Some distros with ten years of support ship an old gcc but later offer
more recent versions for installation in parallel. These versions are
typically not only needed for the compilation of llvm/clang, but also to
properly use the clang binary that comes out.
Clang already searches /usr at runtime for the most recent installation
of gcc. This patch appends paths for add-on installations of gcc in
RHEL.
Patch by Michael Lampe.
llvm-svn: 268912
Summary:
Now that LLVM is emitting version 2 of the AMD code object, we can
start using lld again for linking instead of our custom tool.
Reviewers: arsenm, kzhuravl
Subscribers: rafael, cfe-commits
Differential Revision: http://reviews.llvm.org/D19952
llvm-svn: 268648
r217178 changed clang to add function attribute uwtable by default on
Win64, which caused the __eh_frame section to be emitted by default.
This commit restores the previous behavior for MachO targets.
rdar://problem/25282627
llvm-svn: 268589
This option, like the corresponding gcc option, is SystemZ-specific and
enables storing frame backchain links, as specified in the ABI.
Differential Revision: http://reviews.llvm.org/D19891
llvm-svn: 268575
This reverts commit r264813 / 6484b95d634f53dd929c75265ef3c4decf397584.
While using it in the shell is fine, this a problem when cc1as is
invoked directly by the driver because single quoting the clang full
version makes cc1as write out the version with the quotes in the final
binary.
If the user wants to copy-n-pastable output, it could use either -###
or CC_PRINT_OPTIONS=1 clang -v ...
llvm-svn: 268297
Summary:
This patch adds a new driver warning -Wincompatible-sdk which notifies the user when they are mismatching the version min options and the sysroot.
The patch works by checking the sysroot (if present) for an SDK name, then matching that against the target platform. In the case of a mismatch it logs a warning.
Reviewers: bob.wilson, rsmith
Subscribers: rsmith, edward-san, cfe-commits
Differential Revision: http://reviews.llvm.org/D18088
llvm-svn: 268127
It makes compiler-rt tests fail if the gold plugin is enabled.
Revert "Rework interface for bitset-using features to use a notion of LTO visibility."
Revert "Driver: only produce CFI -fvisibility= error when compiling."
Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi."
llvm-svn: 267871
The -fvisibility= flag only affects compile jobs, so there's no need to
error out because of it if we aren't compiling (e.g. if we are only linking).
llvm-svn: 267824
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.
We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).
If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.
This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.
Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.
Differential Revision: http://reviews.llvm.org/D18635
llvm-svn: 267784
Currently, clang-cl always uses Windows style for unquoting, and clang always
uses POSIX style for unquoting.
With this flag, it's possible to change these defaults.
In general, response file quoting should match the shell the response file is
used in. On Windows, it's possible to run clang-cl in a bash shell, or clang in
cmd.exe, so a flag for overriding the default behavior is natural there.
On non-Windows, Windows quoting probably never makes sense (except maybe in
Wine), but having clang-cl behave differently based on the host OS seems
strange too. So require that people who want to use posix-style response
files with clang-cl on non-Windows pass --rsp-quoting=posix.
http://reviews.llvm.org/D19425
llvm-svn: 267474
Summary:
Adds a framework to enable the instrumentation pass for the new
EfficiencySanitizer ("esan") family of tools. Adds a flag for esan's
cache fragmentation tool via -fsanitize=efficiency-cache-frag.
Adds appropriate tests for the new flag.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19169
llvm-svn: 267059
Summary:
This completes the flag's tristate, letting you override it at will on
the command line.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D19248
llvm-svn: 266707
Summary:
Without this change, we silently proceed on without including
__clang_cuda_runtime_wrapper.h. This leads to very strange behavior --
you say you're compiling CUDA code, but e.g. __device__ is not defined!
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19180
llvm-svn: 266496
We've already paid the price for separate "armv7m" and "armv7em" slices
(support in other tools), it's silly to make them identical other than the
default CPU.
rdar://23055688
llvm-svn: 266211
FreeBSD uses LLVM's libunwind on FreeBSD/arm64 today (and is expected to
use it more widely in the future), and it requires the EH frame segment
in static binaries.
This is the same as r203742 for NetBSD.
Differential Revision: http://reviews.llvm.org/D19029
llvm-svn: 266123
r260990 exposed -isystem in clang-cl. -isystem adds a directory to the front of
the system include search path. The idea was to use this to point to a hermetic
msvc install, but as it turns out this doesn't work: -isystem then adds the
hermetic headers in front of clang's builtin headers, and clang's headers that
are supposed to wrap msvc headers (say, stdarg.h) aren't picked up at all
anymore.
So revert that, and instead expose -imsvc which works as if the passed
directory was part of %INCLUDE%: The header is treated as a system header, but
it is searched after clang's lib/Header headers.
Fixes half of PRPR26751.
llvm-svn: 266108
This is the clang part of http://reviews.llvm.org/D18846.
SafeStack instrumentation pass adds stack protector canaries if both
attributes are present on a function. StackProtector pass will step
back if the function has a safestack attribute.
llvm-svn: 266005
As we're currently working on making CloudABI executables easier to
emulate in userspace (e.g., on OS X and Windows), it makes a whole lot
of sense to build these using PIE. By using PIE, they can simply be
loaded into the existing process address space without clashes.
PIE support got added to CloudABI's C library and seems to work pretty
well. CloudABI does not make use of an ld.so, so the binary's _start()
has all the logic in it to do the relocations.
Now that all but one bug in LLD relating to PIE support have been
squashed (and a patch for that is already in code review), I'd like to
go ahead and force the use of PIE for Clang 3.9. When released, we'll
also switch over to using LLD exclusively.
llvm-svn: 265546
Summary:
Setting this flag causes all functions are annotated with the
"nvvm-f32ftz" = "true" attribute.
In addition, we annotate the module with "nvvm-reflect-ftz" set
to 0 or 1, depending on whether -cuda-flush-denormals-to-zero is set.
This is read by the NVVMReflect pass.
Reviewers: tra, rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18671
llvm-svn: 265435
Add no-jump-tables flag to disable use of jump tables when lowering
switch statements
Reviewers: echristo, hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18407
llvm-svn: 265425
The reproducer should use -I/-F/-resource-dir in the same way as the
original command. The VFS already collects the right headers but without
these flags the reproducer will fail to do the right thing.
llvm-svn: 265343
The cc1 invocation in the reproducer script should contain a valid path in
-fmodule-cache-path; for that reuse "<name>.cache/module" dir we already
use to dump the vfs and modules.
llvm-svn: 265162
Summary:
This prevents errors when you invoke clang with a flag that the NVPTX
toolchain doesn't support. For example, on x86-64,
clang -mthread-model single -x c++ /dev/null -o /dev/null
should output just one error about "invalid thread model 'single' in
'-mthread-model single' for this target"; x86-64 doesn't support
-mthread-model, but we shouldn't also instantiate a NVPTX target!
Reviewers: echristo
Subscribers: tra, sunfish, cfe-commits
Differential Revision: http://reviews.llvm.org/D18629
llvm-svn: 264965
Over the last month we've been testing SafeStack extensively. As far as
we know, it works perfectly fine. That why I'd like to see us having
this enabled by default for CloudABI.
This change introduces a getDefaultSanitizers() function that toolchains
can use to specify which sanitizers are enabled by default. Once all
flags are processed, only flags that had no -fno-sanitize overrides are
enabled.
Extend the thests for CloudABI to test both the default case and the
case in which we want to explicitly disable SafeStack.
Reviewed by: eugenis, pcc
Differential Revision: http://reviews.llvm.org/D18505
llvm-svn: 264787
Summary:
* -fcuda-target-overloads
Previously unconditionally set to true by the driver. Necessary for
correct functioning of the compiler -- our CUDA headers wrapper won't
compile without this.
* -fcuda-disable-target-call-checks
Previously unconditionally set to true by the driver. Necessary to
compile almost any external CUDA code -- almost all libraries assume
that host+device code can call host or device functions.
* -fcuda-allow-host-calls-from-host-device
No effect when target overloading is enabled.
Reviewers: tra
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D18416
llvm-svn: 264739
Most things even work; see the included FIXMEs for things that need polishing.
Also don't warn about unused flags for the `/Yuh2.h /FIh1.h /FIh2.h`. The
common case is that the pch was built with `/Ych2.h /FIh1.h /FIh2.h`, so h1.h
is in the PCH, and we shouldn't warn about /FIh1.h not having an effect.
(If we wanted to get fancy, we could store the list of -include flags in the
pch and then check that it matches later on.)
llvm-svn: 264178
This reverts commit r263607.
This change caused more objc_retain/objc_release calls in the IR but those
are then incorrectly optimized by the ARC optimizer. Work is going to have
to be done to ensure the ARC optimizer doesn't optimize user written RR, but
that should land before this change.
This change will also need to be updated to take account for any changes required
to ensure that user written calls to RR are distinct from those inserted by ARC.
llvm-svn: 263984
Update the clang driver to allow -fsanitize=thread when targeting x86_64 iOS and tvOS
simulators. Also restrict TSan targeting OS X to only be supported on x86_64 and not i386.
Differential Revision: http://reviews.llvm.org/D18280
llvm-svn: 263913
Summary: LLVM_PREFIX could be undefined if CMAKE_INSTALL_PREFIX were set to empty.
Reviewers: kparzysz, bkramer, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17784
llvm-svn: 263766
It is faster to directly call the ObjC runtime for methods such as retain/release instead of sending a message to those functions.
This patch adds support for converting messages to retain/release/alloc/autorelease to their equivalent runtime calls.
Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions.
Reviewed by John McCall.
Differential Revision: http://reviews.llvm.org/D14737
llvm-svn: 263607
Summary: isTarget*() calls are order-dependent. This is because iOS Sim *is* iOS. This means checks for the simulator version of the platform must always be ahead of checks for the embedded platform.
Reviewers: zaks.anna, bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17947
llvm-svn: 263567
Also introduce -stdlib=platform to override the configured value
and use it to make the tests always pass.
Differential Revision: http://reviews.llvm.org/D17286
llvm-svn: 263434
This enables "--rtlib compiler-rt" option under MSVC environment.
Patch by Roman Shirokiy.
Differential Revision: http://reviews.llvm.org/D17453
llvm-svn: 263422
Summary:
This flag is enabled by default in the driver when NDEBUG is set. It
is forwarded on the LLVMContext to discard all value names (but
GlobalValue) for performance purpose.
This an improved version of D18024
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18127
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263394
This patch extends the -fuse-ld option to accept a full path to an executable
and use it verbatim to invoke the linker. There are generally two reasons
to desire this.
The first reason relates to the sad truth is that Clang is retargetable,
Binutils are not.
While any Clang from a binary distribution is sufficient to compile code
for a wide range of architectures and prefixed BFD linkers (e.g.
installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as cross-compiled
libc's (for non-bare-metal targets) are widely available, including on all
Debian derivatives, it is impossible to use them together because
the -fuse-ld= option allows to specify neither a linker prefix nor
a full path to one.
The second reason is linker development, both when porting existing linkers
to new architectures and when working on a new linker such as LLD.
Differential Revision: http://reviews.llvm.org/D17952
llvm-svn: 262996
Now that pragma comment and pragma detect_mismatch are implemented, this might
just work.
Some pragmas aren't serialized yet (from the top of my head: code_seg, bss_seg,
data_seg, const_seg, init_seg, section, vtordisp), but these are as far as I
know usually pushed and popped within the header and usually don't leak out.
If it turns out the current PCH support isn't good enough yet, we can turn it
off again.
llvm-svn: 262749
Summary:
Using -no-integrated-as causes -mcpu=krait to be transformed into
-march=armv7-a today. This precludes the assembler from using
instructions like sdiv, which are present for krait. Cortex-a15 is the
closest subset of functionality for krait, so we should switch the
assembler to use that instead.
Reviewers: cfe-commits, apazos, weimingz
Subscribers: aemerson
Differential Revision: http://reviews.llvm.org/D17874
llvm-svn: 262742
This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-instr-use=<path> is now a driver only option.
In addition to decouple the cc1 option from the driver level option, this patch
also enables IR level profile use. cc1 option handling now reads the profile
header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM}
-- this is a common enum for -fprofile-instrument={}, for the profile
instrumentation), and invoke the pipeline to enable the respective PGO use pass.
Reviewers: silvas, davidxl
Differential Revision: http://reviews.llvm.org/D17737
llvm-svn: 262515
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
llvm-svn: 262420
Summary:
This is the clang driver part of the change to embedded bitcode. This
includes:
1. -fembed-bitcode option which breaks down the compilation into two
stages. The first stage emits optimized bitcode and the second stage
compiles bitcode into object file.
2. -fembed-bitcode-marker option which doesn't really break down to
two stages to speedup the compilation flow.
3. pass the correct linker flag to darwin linker if tool chains supports
embedded bitcode.
Reviewers: rsmith, thakis
Subscribers: thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D17390
llvm-svn: 262282
Functions with an explicit exception specification have their behavior
dictated by the specification. The additional /EHc behavior only comes
into play if no exception specification is given.
llvm-svn: 262198
Summary:
(Re-land of r260448, which was reverted in r260522 due to a test failure
in Driver/output-file-cleanup.c that only showed up in fresh builds.)
Previously we attempted to be smart; if one job failed, we'd run all
jobs that didn't depend on the failing job.
Problem is, this doesn't work well for e.g. CUDA compilation without
-save-temps. In this case, the device-side and host-side Assemble
actions (which actually are responsible for preprocess, compile,
backend, and assemble, since we're not saving temps) are necessarily
distinct. So our clever heuristic doesn't help us, and we repeat every
error message once for host and once for each device arch.
The main effect of this change, other than fixing CUDA, is that if you
pass multiple cc files to one instance of clang and you get a compile
error, we'll stop when the first cc1 job fails.
Reviewers: echristo
Subscribers: cfe-commits, jhen, echristo, tra, rafael
Differential Revision: http://reviews.llvm.org/D17217
llvm-svn: 261774
This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.
Differential Revision: http://reviews.llvm.org/D16821
llvm-svn: 261767
Also introduce inputs() that reutnrs an llvm::iterator_range.
Iterating over A->inputs() is much less mysterious than
iterating over *A. No intended behavior change.
llvm-svn: 261674
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
Our support for C++ EH is sufficiently good that it makes sense to
enable support for it out of the box.
While we are here, update the MSVCCompatibility doc.
llvm-svn: 261195
Summary:
I've got a patchset in my home directory to integrate support for
SafeStack into CloudABI's C library. All of the CloudABI unit tests
still seem to pass. Pretty sweet!
This change adds the necessary changes to Clang to make
-fsanitize=safe-stack work on CloudABI. Without it, passing this command
line flag throws an error.
Reviewers: eugenis, samsonov
Differential Revision: http://reviews.llvm.org/D17243
llvm-svn: 261135
ptxas optimizations are disabled if we need to generate debug info
as ptxas does not accept '-g' otherwise.
Differential Revision: http://reviews.llvm.org/D17111
llvm-svn: 261018
I'd accidentally skipped the CMake check in a premature optimisation. I'd also
put the original test in completely the wrong place.
Thanks Jonas Hahnfeld!
llvm-svn: 260898
C++ programs compiled for profiling (using `-pg`) should be linked with
`-lc++_p` (or `-lstdc++_p`, depending on the `-stdlib=` setting), not
with the regular C++ libraries.
Add a `FreeBSD::AddCXXStdlibLibArgs()` override to handle this, and add
a test case for it. While here, extend the test case for the proper
passing of -lm and -lm_p.
Reviewers: compnerd, davide, dws, emaste
Reviewed By: compnerd
Differential Revision: http://reviews.llvm.org/D16264
llvm-svn: 260851
With this option one can optionally override the architecture dependent
default library to use if no -stdlib= is provided on compiler invocation.
Differential Revision: http://reviews.llvm.org/D15920
llvm-svn: 260662
This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the
triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a).
The FP16 extension can be enabled with the "+fp16" suffix to the -march
or -mcpu option. This is consistent with the AArch64 option, rather than
the usual ARM option of -mfpu. We have agreed with the team which will
be upstreaming this to GCC that we want to use this new option format
for new architecture extensions for both ARM and AArch64.
Most of the work for this was done by the TargetParser patch in llvm.
Differential Revision: http://reviews.llvm.org/D15040
llvm-svn: 260533
Summary:
Actions don't depend on the toolchain; they get bound to a particular
toolchain via BindArch.
No functional changes.
Reviewers: echristo
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17100
llvm-svn: 260478
Previously we attempted to be smart; if one job failed, we'd run all
jobs that didn't depend on the failing job.
Problem is, this doesn't work well for e.g. CUDA compilation without
-save-temps. In this case, the device-side and host-side Assemble
actions (which actually are responsible for preprocess, compile,
backend, and assemble, since we're not saving temps) are necessarily
distinct. So our clever heuristic doesn't help us, and we repeat every
error message once for host and once for each device arch.
The main effect of this change, other than fixing CUDA, is that if you
pass multiple cc files to one instance of clang and you get a compile
error, we'll stop when the first cc1 job fails.
Reviewers: tra, echristo
Subscribers: jhen, cfe-commits
Differential Revision: http://reviews.llvm.org/D16514
llvm-svn: 260448
Previously LLVM could not process any debug info we produced, so it
didn't make sense to spend time generating it. Now that it has primitive
support for local variable info, it does make sense to generate normal
debug info.
llvm-svn: 260435
Adjust the driver to invoke the linker more similar to gcc. -dynamic-linker is
only passed if -static and -shared are not part of the compiler (driver)
invocation. Replicate the passing of -export-rdynamic as per the GCC link spec:
%{!static: %{rdynamic:-export-dynamic} %{!shared:-dynamic-linker ...}}
This behaviour is consistent across all the targets that are supported, so no
need to conditionalise it on the target.
Resolves PR24245.
llvm-svn: 260019
This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.
Review: http://reviews.llvm.org/D16730
llvm-svn: 259811
Various bits we'd like to use the new ABI actually compile with "-arch armv7k
-miphoneos-version-min=9.0". Not ideal, but also not ridiculous given how
slices work.
llvm-svn: 258976
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
Support for the -fno-math-builtin option was added in r186899. The codegen side
is being tested in test/CodeGen/nomathbuiltin.c. The missing part was just
passing the option through the driver.
PR26317
llvm-svn: 258814
* Runtime diagnostic data for cfi-icall changed to match the rest of
cfi checks
* Layout of all CFI diagnostic data changed to put Kind at the
beginning. There is no ABI stability promise yet.
* Call cfi_slowpath_diag instead of cfi_slowpath when needed.
* Emit __cfi_check_fail function, which dispatches a CFI check
faliure according to trap/recover settings of the current module.
* A tiny driver change to match the way the new handlers are done in
compiler-rt.
llvm-svn: 258745
Summary:
MSVC's driver accepts all unknown arguments but warns about them. clang
by default rejects all unknown arguments. This causes issues
specifically with build systems such as autoconf which liberally pass
things such as $LDFLAGS to the compiler and expect everything to work.
This patch teaches clang-cl to ignore unknown driver arguments.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16511
llvm-svn: 258720
From
https://gcc.gnu.org/ml/gcc-patches/2010-09/msg01807.html
-fsplit-stack should pass --wrap=pthread_create to linker for -fsplit-stack
It is needed to initialize the stack guard. This fixes PR 20148.
Patch by H.J Lu!
llvm-svn: 258698
Microsoft's documentation states that specifying
/Oy- after the /O[12x] options disables frame-pointer omission.
What it does *not* state is that it also disables frame-pointer omission
if /Oy- is specified before /O[12x].
llvm-svn: 258447
Many of the "unix" checkers are not actually unix-specific and would be valuable
to run on Windows. This commit explicitly enables those checkers on
Windows.
A patch by Alexander Riccio!
Differential Revision: http://reviews.llvm.org/D16245
llvm-svn: 258426
Summary:
Previously we'd crash the driver if you passed -O0. Now we try to
handle all of clang's various optimization flags in a sane way.
Reviewers: tra
Subscribers: cfe-commits, echristo, jhen
Differential Revision: http://reviews.llvm.org/D16307
llvm-svn: 258174
FIXME: Add more targets to use emutls into clang/test/Driver/emulated-tls.cpp.
FIXME: Add cygwin tests into llvm/test/CodeGen/X86. Working in progress.
llvm-svn: 257984
Summary:
It's possible to BindArch without changing the toolchain at all. For
example, armv7 and armv7s have exactly the same toolchain triple.
Therefore the code in the Driver that checks that we're not creating a
job for the same Action twice needs to consider (Action, Toolchain,
BoundArch) tuples.
Reviewers: tra
Subscribers: aemerson, echristo, beanz, cfe-commits
Differential Revision: http://reviews.llvm.org/D16250
llvm-svn: 257983
This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.
Differential Revision: http://reviews.llvm.org/D16175
llvm-svn: 257971
Summary:
Previously we compiled CUDA device code to PTX assembly and embedded
that asm as text in our host binary. Now we compile to PTX assembly and
then invoke ptxas to assemble the PTX into a cubin file. We gather the
ptx and cubin files for each of our --cuda-gpu-archs and combine them
using fatbinary, and then embed that into the host binary.
Adds two new command-line flags, -Xcuda_ptxas and -Xcuda_fatbinary,
which pass args down to the external tools.
Reviewers: tra, echristo
Subscribers: cfe-commits, jhen
Differential Revision: http://reviews.llvm.org/D16082
llvm-svn: 257809
Summary:
Right now if the Action graph is a DAG and we encounter an action twice,
we will run it twice.
This patch is difficult to test as-is, but I have testcases for this as
used within CUDA compilation.
Reviewers:
Subscribers:
llvm-svn: 257808
The PIC default is set for the MachO toolchain, not just the Darwin toolchain,
so this treats those the same. The behavior with -static should be the same
for all MachO targets. rdar://24152327
llvm-svn: 257556
There was a thinko in the deployment target detection code that
made the -isysroot parsing have precedence over the environment
variable for tvOS. This patch makes this logic symetric for all
platforms (the env variable must have precedence).
llvm-svn: 257543
Summary: This is used by D16082 when it invokes fatbinary.
Reviewers: tra
Subscribers: cfe-commits, jhen, echristo
Differential Revision: http://reviews.llvm.org/D16097
llvm-svn: 257530
Will re-apply after llvm 3.8 is branched.
Original commit message:
Driver: fallback to the location of clang if no sysroot,
hard coding /usr makes little sense for mingw-w64.
If we have portable toolchains having /usr breaks that.
If the clang we use is in /usr/bin or /usr/sbin etc this will
still detect as though it was hard coded to /usr
This makes the most sense going forward for mingw-w64 toolchains
on both linux and mac
llvm-svn: 257468
Summary:
The CUDA toolchain needs to know which Actions created which InputInfos,
because it needs to attach GPU archs to the various InputInfos.
Reviewers: echristo
Subscribers: jfb, dschuff, jhen, tra, cfe-commits
Differential Revision: http://reviews.llvm.org/D16078
llvm-svn: 257411
Summary:
This makes constructing Action graphs which are DAGs much simpler. It
also just simplifies in general the ownership semantics of Actions.
Depends on D15910.
Reviewers: echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D15911
llvm-svn: 257407
Summary:
Use llvm::any_of, llvm::find, etc.
No functional changes.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15936
llvm-svn: 257190
Summary: 'gnu-old' has been deprecated in favor or 'gnu'.
Reviewers: arsenm, ruiu, rafael
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15953
llvm-svn: 257175
Summary:
This is the clang part of D15966. In rL256104, debugger tuning was
added to the clang driver, and again the default for FreeBSD was set to
lldb. The default needs to be gdb instead.
Reviewers: emaste, probinson
Subscribers: cfe-commits, emaste
Differential Revision: http://reviews.llvm.org/D15967
llvm-svn: 257104
This will eventually be accompanied with a change to enable -ffunction-sections
and -fdata-sections by default, which is currently delayed by some development
process issues.
llvm-svn: 256967
Summary: This patch removes security.*, unix.API and unix.Vfork from the default checkers for PS4.
Reviewers: dcoughlin, zaks.anna
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15888
llvm-svn: 256926
Summary:
In rL256641, @davide turned off movt generation by default for FreeBSD.
This was because our ld is very old, and did not support the relocations
for it. However, Ian Lepore added the support very recently, so we
would like to revert rL256641, and replace it with a new `-fno-movt`
frontend option. This way, it can be turned off when needed.
Reviewers: dexonsmith, echristo, emaste, davide
Subscribers: andrew, aemerson, rengolin, davide, cfe-commits, ahatanak, emaste
Differential Revision: http://reviews.llvm.org/D15899
llvm-svn: 256920
A gcc tool has an "integrated" assembler (usually gas) that it
will call to produce an object. Let it use that assembler so
that we don't have to deal with assembly syntax incompatibilities.
llvm-svn: 256919
Summary:
LLVM part of the patch is D15831.
When clang runs an external tool such as a linker it may create a command line that exceeds the length limit.
Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS
limitation. There are two problems in this function that may cause exceeding of the limit:
1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program
path to the command line when it runs the program.
2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails.
Reviewers: rafael, asl
Subscribers: asl, llvm-commits
Differential Revision: http://reviews.llvm.org/D15832
llvm-svn: 256865
Summary: This change enables clang to automatically link binaries built with the -fprofile-instr-generate against the clang_rt.profile-i386.lib library.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15833
llvm-svn: 256855
It's sort of an hack, but we have no choice.
The linker in the base system doesn't handle that correctly (yet).
Once FreeBSD will import lld, this can be backed out.
Patch by: Andrew Turner!
llvm-svn: 256641
the front end as well.
Note that DWARF5 isn't finalized and any feature support is subject to
change and accepting of the option doesn't mean we're supporting the
full range of the current standard.
llvm-svn: 256516
Summary:
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=25597 ]
Clang support for DragonFly BSD is lagging a bit, resulting in poor
support for c++.
DragonFlyBSD is unique in that it has two base compilers. At the time
of the last Clang update for DragonFly, these compilers were GCC 4.4 and
GCC 4.7 (default).
With DragonFly Release 4.2, GCC 4.4 was replaced with GCC 5.0, partially
because the C++11 support of GCC 4.7 was incomplete. The DragonFly
project will Release version 4.4 soon.
This patch updates the Clang driver to use libstdc++ from GCC 5.2 The
support for falling back to the alternate compiler was removed for two
reasons:
1) The last release to use GCC 4.7 is DF 4.0 which has already reached EOL
2) GCC 4.7 libstdc++ is insufficient for many "ports"
Therefore, I think it is reasonable that the development version of
clang expects GCC 5.2 to be in place and not try to fall back to another
compiler.
The attached patch will do this. The Tools.cpp file was signficantly
modified to fix the linking which had been changed somewhere along the
line. The rest of the changes should be self-explanatory.
Reviewers: joerg, rsmith, davide
Subscribers: jrmarino, davide, cfe-commits
Differential Revision: http://reviews.llvm.org/D15166
llvm-svn: 256467
The /Brepro flag controls whether or not the compiler should embed
timestamps into the object file. Object files which do not embed
timestamps are not suitable for incremental linking but are suitable for
hermetic build systems and staged self-hosts of clang.
A normal clang spelling of this flag has been added,
-mincremental-linker-compatible.
llvm-svn: 256204
Adds driver options named -glldb and -gsce to mean -g plus tuning for
lldb and SCE debuggers respectively; the existing -ggdb option does
the same for gdb. Existing options -ggdb0, -ggdb1 etc. unpack into
-ggdb -g<N>. (There will not be -glldb<N> or -gsce<N> options.) The
tuning gets a target-specific default in the driver, and is passed
into cc1 with the new -debugger-tuning option.
As fallout, fixes where '-gsplit-dwarf -g0' would ignore the -g0 part
on Linux.
Differential Revision: http://reviews.llvm.org/D15651
llvm-svn: 256104
r245667 changed -static so that it doesn't override an explicit -fPIC
option, but -static should still change the default for Darwin for -fno-PIC.
This matches longstanding GCC and Clang behavior on Darwin and changing it
would be disruptive, with no significant benefit.
http://reviews.llvm.org/D15455
rdar://problem/23811045
llvm-svn: 256026
This begins minimal support for invoking 'ld' from clang for WebAssembly
targets.
Differential Revision: http://reviews.llvm.org/D15586
llvm-svn: 255848
".exe" extension is inherently checked by llvm::fs::can_execute()
This patch fixes the linker extension in clang driver and updates the
unit test to accommodate the the check string on windows.
Differential Revision:http://reviews.llvm.org/D15577
llvm-svn: 255814
Currently it's easy to break CUDA compilation by passing
"-isystem /path/to/cuda/include" to compiler which leads to
compiler including real cuda_runtime.h from there instead
of the wrapper we need.
Renaming the wrapper ensures that we can include the wrapper
regardless of user-specified include paths and files.
Differential Revision: http://reviews.llvm.org/D15534
llvm-svn: 255802
Clang-side cross-DSO CFI.
* Adds a command line flag -f[no-]sanitize-cfi-cross-dso.
* Links a runtime library when enabled.
* Emits __cfi_slowpath calls is bitset test fails.
* Emits extra hash-based bitsets for external CFI checks.
* Sets a module flag to enable __cfi_check generation during LTO.
This mode does not yet support diagnostics.
llvm-svn: 255694
This patch enables soft float support for ppc32 architecture and fixes
the ABI for variadic functions. This is the first in a set of patches
for soft float support in LLVM.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D13351
llvm-svn: 255515
- Removed support for hexagonv3 and earlier.
- Added handling of hexagonv55 and hexagonv60.
- Added handling of target features (hvx, hvx-double).
- Updated paths to reflect current directory layout.
llvm-svn: 255502
This improves the coverage for the multilib directories used for ARM. Also add
tests covering the internal triple (thumbv7-*). The Juno board can be run in
this configuration.
llvm-svn: 255328
Summary:
Adds new option -fthinlto-index=<file> to invoke the LTO pipeline
along with function importing via clang using the supplied function
summary index file. This supports invoking the parallel ThinLTO
backend processes in a distributed build environment via clang.
Additionally, this causes the module linker to be invoked on the bitcode
file being compiled to perform any necessary promotion and renaming of
locals that are exported via the function summary index file.
Add a couple tests that confirm we get expected errors when we try to
use the new option on a file that isn't bitcode, or specify an invalid
index file. The tests also confirm that we trigger the expected function
import pass.
Depends on D15024
Reviewers: joker.eph, dexonsmith
Subscribers: joker.eph, davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D15025
llvm-svn: 254927
This patch is a fix to r252901 which changed the behavior of
clang driver. In the presence of "-nostdlib" none of the standard
libraries should be passed to link line.
Differential Revision: http://reviews.llvm.org/D15130
llvm-svn: 254535
handling is corrected, the primary reason for forcing IAS as default is
gone and the remaining issues are still somewhat problematic in common
situations.
llvm-svn: 254199
This adds the "+profile" and +noprofile" suffixes for the -march and
-mcpu options, to allow enabling or disabling the options Statistical
Profiling Extension to ARMv8.2-A.
Differential Revision: http://reviews.llvm.org/D15023
llvm-svn: 254161
This adds new values for the -march option (armv8.2a and armv8.2-a,
which are aliases of each other), and new suffixes for the -march and
-mcpu options (+fp16 and +nofp16), to allow targeting the ARMv8.2-A
architecture and it's optional half-precision floating-point extension.
Differential Revision: http://reviews.llvm.org/D15022
llvm-svn: 254160
The Driver only checked if nostdlib was set when deciding to add
reserved_lib_stdcxx, but as nostdlib is always exactly nodefaultlibs and
nostartfiles we should be checking one (clearly nodefaultlibs in the
case) as well. This appears to be the only such instance of this in the
codebase.
Differential Revision: http://reviews.llvm.org/D14935
llvm-svn: 253990
hard coding /usr makes little sense for mingw-w64.
If we have portable toolchains having /usr breaks that.
If the clang we use is in /usr/bin or /usr/sbin etc this will
still detect as though it was hard coded to /usr
This makes the most sense going forward for mingw-w64 toolchains
on both linux and mac
Differential Revision: http://reviews.llvm.org/D14164
llvm-svn: 253898
(Re-apply patch after bug fixing)
This diff makes sure that the driver does not pass
-fomit-frame-pointer or -momit-leaf-frame-pointer to
the frontend when -pg is used. Currently, clang gives
an error if -fomit-frame-pointer is used in combination
with -pg, but -momit-leaf-frame-pointer was forgotten.
Also, disable frame pointer elimination in the frontend
when -pg is set.
Patch by Stefan Kempf.
llvm-svn: 253886
This diff makes sure that the driver does not pass
-fomit-frame-pointer or -momit-leaf-frame-pointer to
the frontend when -pg is used. Currently, clang gives
an error if -fomit-frame-pointer is used in combination
with -pg, but -momit-leaf-frame-pointer was forgotten.
Also, disable frame pointer elimination in the frontend
when -pg is set.
Patch by Stefan Kempf.
llvm-svn: 253846
Cross compiling from linux and OSX results in Error: Exec format.
This is because the linker is expecting ELF formated objects.
By passing the target we can explicitly tell the linker that
it should be linking COFF objects regardless of the host.
llvm-svn: 253813
This allows us to construct Linux toolchains without a valid linker. This
is needed for example to build a CUDA device toolchain after r253385.
llvm-svn: 253707
Summary: This code is a bit undesirable, but it gets clang to work with the autoconf and cmake-built libclang_rt.profile libraries.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14847
llvm-svn: 253625
Currently clang requires several additional command
line options in order to enable new features needed
during CUDA compilation. This patch makes these
options default.
* Automatically include cuda_runtime.h if we've found
a valid CUDA installation.
* Disable automatic CUDA header inclusion during unit tests.
* Added test case for command line construction.
* Enabled target overloads and relaxed call checks that are
needed in order to include CUDA headers.
* Added CUDA-7.5 installation path to the CUDA installation search list.
* Define __CUDA__ macro to indicate CUDA compilation.
llvm-svn: 253389
- added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for.
- pass additional cc1 options for linking with detected libdevice bitcode
- added -nocudalib to prevent automatic linking with libdevice
- added test cases to verify new functionality
Differential Revision: http://reviews.llvm.org/D14556
llvm-svn: 253387
In order to compile a CUDA file clang must be able to find
include files for both both host and device.
This patch passes AuxToolchain to AddPreprocessingOptions and
uses it to add include paths for the opposite side of compilation.
We also must be able to find CUDA include files. If the driver
found CUDA installation, it adds appropriate include path
to CUDA headers. This can be disabled with '-nocudainc'.
- Added include paths for the opposite side of compilation.
- Added include paths to detected CUDA installation.
- Added -nocudainc to prevent adding CUDA include path.
- Added test cases to verify new functionality.
Differential Revision: http://reviews.llvm.org/D13170
llvm-svn: 253386
Clang needs to know target triple for both sides of compilation so that
preprocessor macros and target builtins from both sides are available.
This change augments Compilation class to carry information about
toolchains used during different CUDA compilation passes and refactors
BuildActions to use it when it constructs CUDA jobs.
Removed DeviceTriple from CudaHostAction/CudaDeviceAction as it's no
longer needed.
Differential Revision: http://reviews.llvm.org/D13144
llvm-svn: 253385
"-arch armv7k" is only normally used with a watchos target, but Clang doesn't
stop you from giving a "-miphoneos-version-min" option too, converting the
triple to "thumbv7k-apple-ios". In this case the backend will decide to use
SjLj exceptions, so Clang needs to agree so it can create the correct
predefines.
Fortunately, there's a handy function to make the decision for us now.
llvm-svn: 253355
Last time, this caused two Windows buildbots and a single ARM buildbot to fail.
I XFAIL'd the failing test on win32,win64 machines in order to see if the ARM
buildbot complains again.
llvm-svn: 252901
This currently changes the default toward the more historic -Av8/-Av9,
but as discussed with James Y Knight, consistency is for now more
important than figuring out which default CPU each OS should be using.
llvm-svn: 252571
When adding profiling instrumentation, use libclang_rt.profile_tvos.a
for TVOS targets and libclang_rt.profile_watchos.a for WatchOS targets.
I've also fixed up a comment and added an assert() that prevents us from
defaulting to an incorrect platform.
Differential Revision: http://reviews.llvm.org/D14521
Reviewed-by: t.p.northover
llvm-svn: 252558
is not defined for 32bit mode, but __sparcv9 is. Pass down the correct
-target-cpu flags to the backend, so that instruction restrictions are
applied correctly. Pass down the correct -A flag when not using IAS.
The latter is limited to NetBSD targets in this commit.
llvm-svn: 252545
The -meabi flag to control LLVM EABI version.
Without '-meabi' or with '-meabi default' imply LLVM triple default.
With '-meabi gnu' sets EABI GNU.
With '-meabi 4' or '-meabi 5' set EABI version 4 and 5 respectively.
A similar patch was introduced in LLVM.
Patch by Vinicius Tinti.
llvm-svn: 252463
We're currently in process of porting TSan to OS X, and quite a few of the initial support in the runtime library has already landed in trunk. This patch actually enables "-fsanitize=thread" in the frontend.
Differential Revision: http://reviews.llvm.org/D14440
llvm-svn: 252310
This sets the mostly expected Darwin default ABI options for these two
platforms. Active changes from these defaults for watchOS are in a later patch.
llvm-svn: 251708
This patch should add support for almost all command-line options and
driver tinkering necessary to produce a correct "clang -cc1"
invocation for watchOS and tvOS.
llvm-svn: 251706
This reverts commit r251695. Debug is meant to be done off tree, not use the buildbots
experiments. I'll help investigate this problem off trunk.
llvm-svn: 251696
This should be a NFC for every toolchain other than mips-mti-linux (where we
print the list of directories searched for crt files). It will soon be
reverted once we hit the clang-cmake-armv7-a15-selfhost-neon buildbot.
llvm-svn: 251695
The original commit in r249137 added the mips-mti-linux toolchain. However,
the newly added tests of that commit failed in few buildbots. This commit
re-applies the original changes but XFAILs the test file which caused
the buildbot failures. This will allow us to examine what's going wrong
without having to commit/revert large changes.
llvm-svn: 251633
Indicate support for ASAN on the CrossWindows toolchain. Although this is
insufficient, this at least permits the handling of the driver flag.
llvm-svn: 251598
that has a thumb only CPU by default (cortex-m3), and when using the assembler,
the default thumb state of the CPU does not get passed via the triple to LLVM:
$ clang -target thumbv7m-none-eabi -c -v test.s
clang -cc1as ... -triple armv7m-none--eabi ... test.s
Differential Revision: http://reviews.llvm.org/D14121
llvm-svn: 251507
Summary: This is a follow on to post review comments on revision r248276.
Patch by Scott Egerton.
Reviewers: vkalintiris, dsanders
Subscribers: joerg, rengolin, cfe-commits
Differential Revision: http://reviews.llvm.org/D13100
llvm-svn: 251430
Create undef reference to profile hook symbol when
PGO instrumentation is turned on. This allows
LLVM to omit emission of hook variable use method
for every single module instrumented.
llvm-svn: 251385
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
In this patch, the file static method addProfileRT is
moved to be a virtual member function of base ToolChain class.
This allows derived toolchain to override the default behavior
easily and make it consistent with Darwin toolchain (a TODO was
added for this refactoring - now removed). A new helper method
is also introduced to test if instrumentation profile option
is turned on or not.
Differential Revision: http://reviews.llvm.org/D13326
llvm-svn: 250994
Since r249754 MemorySanitizer should work equally well for PIE and
non-PIE executables on Linux/x86_64.
Beware, with this change -fsanitize=memory no longer adds implicit
-fPIE -pie compiler/linker flags on Linux/x86_64.
This is a re-land of r250941, limited to Linux/x86_64 + a very minor
refactoring in SanitizerArgs.
llvm-svn: 250949
Since r249754 MemorySanitizer should work equally well for PIE and
non-PIE executables.
Beware, with this change -fsanitize=memory no longer adds implicit
-fPIE -pie compiler/linker flags, unless the target defaults to PIE.
llvm-svn: 250941
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
Summary:
Similar to rL248426 (which was a followup to rL248379 and rL248424), add the
required libraries for OpenMP on the linker command line, and update the test
case.
Reviewers: emaste, theraven, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13822
llvm-svn: 250657
This recommits r250398 with fixes to the tests for bot failures.
Add "-target x86_64-unknown-linux" to the clang invocations that
check for the gold plugin.
llvm-svn: 250455
Rolling this back for now since there are a couple of bot failures on
the new tests I added, and I won't have a chance to look at them in detail
until later this afternoon. I think the new tests need some restrictions on
having the gold plugin available.
This reverts commit r250398.
llvm-svn: 250402
Summary:
Add clang support for -flto=thin option, which is used to set the
EmitFunctionSummary code gen option on compiles.
Add -flto=full as an alias to the existing -flto.
Add tests to check for proper overriding of -flto variants on the
command line, and convert grep tests to FileCheck.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D11908
llvm-svn: 250398
There was a minor problem with a test. Sorry for the noise yesterday.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250293
Resubmitting the patch.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250262
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250252
This is what most people want anyways. Clang -cc1's main() will override
this but for other tools this is the most sensible default and avoids
some work.
llvm-svn: 250164
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
llvm-svn: 250094
C++ exceptions are still off by default, which is similar to how C++
cleanups are off by default in MSVC.
If you use clang instead of clang-cl, exceptions are also still off by
default. In the future, when C++ EH is proven to be stable, we may flip
the default for that driver to be consistent with other platforms.
llvm-svn: 249704
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.
This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.
llvm-svn: 249294
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
The Windows on ARM ABI recommends that FPO be disabled. This is since the
Windows on ARM ABI uses the FP for fast stack walking. By paying the slight
cost of the loss of registers, a much faster backtrace is possible by using the
frame pointer since the pdata need not be consulted. Furthermore, even if pdata
is not available, you can still more easily reconstruct the stack.
llvm-svn: 249227
Reapply r248935.
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
llvm-svn: 249143
Summary:
This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld,
libcxx, etc. Because of this, it doesn't require neither an existing GCC
installation nor a GNU environment. Ideally, in a follow-up patch we
would like to add a new --{llvm|clang}-toolchain option (similar to
--gcc-toolchain) in order to allow the use of this toolchain with
independent Clang builds. For the time being, we use the --sysroot
option just to test the correctness of the paths generated by the
driver.
Reviewers: atanasyan, dsanders, rsmith
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits
Differential Revision: http://reviews.llvm.org/D13340
llvm-svn: 249137
Summary:
This patch moves getCompilerRT() from the clang::driver::tools namespace to
the ToolChain class. This is needed for multilib toolchains that need to
place their libraries in Clang's resource directory with a layout that is
different from the default one.
Reviewers: atanasyan, rsmith
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13339
llvm-svn: 249030
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
llvm-svn: 248932
ARM EABI adds target attributes to the object file. Amongst the attributes that
are emitted is the VFP argument passing (Hard vs Soft). The linker is
responsible for checking these attributes and erroring on mismatches. This
causes problems for the compiler-rt builtins when targeting both hard and
soft. Because both of these options name the builtins compiler-rt component
the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC
is able to get away with this as it does one target per toolchain. This
changes the naming convention for the ARM compiler-rt builtins to differentiate
between HF and Soft. Although this means that compiler-rt may be duplicated, it
enables supporting both variants from a single toolchain. A similar approach is
taken by the Darwin toolchain, naming the library to differentiate between the
calling conventions.
llvm-svn: 248649
logic to select an alternate target based on the executable it was
called as. For instance, if you symlink i686-linux-android-gcc to clang
and invoke it, the driver will act as though it were called with another
argument ("-target i686-linux-android"). This leads to visible effects
even in syntax-only compilations (like the ANDROID preprocessor symbol
being defined).
This behavior is not replicated for tool invocations--for instance,
clang::createInvocationFromCommandLine will not choose an alternate
target based on ArgList[0]. This means that configurations stored in
compilation databases aren't accurately replayed.
This patch separates the logic for selecting a mode flag and target from
the executable name into a new member function on ToolChain. It should
have no functional effects (but will allow other code to reuse the
target/mode selection logic).
Patch by Luke Zarko!
llvm-svn: 248592
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D11279
llvm-svn: 248546
StringRefs always point to immutable memory so the const doesn't add value
here. Also quiets clang's -Wrange-loop-analysis which warns about the implicit
copying.
llvm-svn: 248496
Summary:
Strictly speaking, the MIPS*R2 ISA's should not permit -mnan=2008 since this
feature was added in MIPS*R3. However, other toolchains permit this and we
should do the same.
Reviewers: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13057
llvm-svn: 248481
Fix of dangling StringRef after temporary std::string is destroyed
Follow-up to: http://reviews.llvm.org/rL248479
Reviewers: alexfh
Subscribers: cfe-commits
llvm-svn: 248480
Fix of dangling StringRef after temporary std::string is destroyed
Follow-up to: http://reviews.llvm.org/rL248370
Reviewers: alexfh
Subscribers: cfe-commits
llvm-svn: 248479
Summary:
With Windows 10 SDK, Include and Lib directories now contain an additional subfolder with the name that corresponds to the full version of the SDK, for example:
- C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um
- C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\um\x64
Reviewers: ruiu, rnk
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D12832
llvm-svn: 248463
Summary:
This corresponds to a patch to compiler-rt (D13112).
Xcode 7 doesn't support targeting iOS5 and earlier. Instead of just dropping cc_kext_ios5, I've repurposed it to cc_kext_ios, and I'm pulling the iOS architectures out of cc_kext. Putting OS X and iOS slices inside the same archive was just odd.
Reviewers: bogner, bob.wilson
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13113
llvm-svn: 248442
Added new option --cuda-path=<path> which allows
overriding default search paths.
If it's not specified we look for CUDA installation in
/usr/include/cuda and /usr/include/cuda-7.0.
Differential Revision: http://reviews.llvm.org/D12989
llvm-svn: 248433
Added new option --cuda-path=<path> which allows
overriding default search paths.
If it's not specified we look for CUDA installation in
/usr/include/cuda and /usr/include/cuda-7.0.
Differential Revision: http://reviews.llvm.org/D12989
llvm-svn: 248408
This translates to -load name.so in the cc1 command. We can't name the driver
option -load, as that means "link against oad", so instead we follow GCC's lead
and name the option -fplugin.
llvm-svn: 248378
An assertion hit has been fixed for cmdlines like
$ clang --target=arm-linux-gnueabi -mcpu=generic hello.c
Related to: http://reviews.llvm.org/rL245445
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13013
llvm-svn: 248370
* Only the last of the --cuda-host-only/--cuda-device-only options has effect.
* CudaHostAction always wraps host-side compilation now.
* Fixed printing of empty action lists.
Differential Revision: http://reviews.llvm.org/D12892
llvm-svn: 248297
This changes getARMFloatABI to use the ToolChain and Args instead of Driver,
Args, Triple. Although this pushes the Triple calculation/parsing into the
function itself, it enables the use of the function for a future change. The
reason to sink the triple calculation here is to avoid threading the Triple
through multiple layers in a future change.
llvm-svn: 248095
Rather than using re-calculating the effective triple, thread the already
calculated value down into AddARMTargetArgs. This avoids both recreating the
triple, as well as re-parsing the triple as it was already done in the previous
frame.
llvm-svn: 248094
Use an enumeration for the Floating Point ABIs supported on MIPS. This is
replicating the ARM change to avoid string based tracking of the floating point
ABI. NFC.
llvm-svn: 248083
NAKAMURA Takumi