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
Use an enumeration and change the use of the FloatABI from a string to the
enumeration. This avoids the use of string values to represent an enumeration.
NFC.
llvm-svn: 247967
There is no __cxa_finalize symbol available on recent Solaris OS
versions, so we need this flag to make non trivial C++ programs run.
Also stop looking for cxa_finalize.o, since it won't be there.
Patch by Xan López!
llvm-svn: 247634
This is actually needed, otherwise libc won't be added at all. For
instance when building libclang.so all the libc symbols won't be
found, with ld warning about libc being an "implicit dependency".
Patch by Xan López!
llvm-svn: 247603
-force-align-stack.
Also, make changes to the driver so that -mno-stack-realign is no longer
an option exposed to the end-user that disallows stack realignment in
the backend.
Differential Revision: http://reviews.llvm.org/D11815
llvm-svn: 247451
Summary:
With Visual Studio 2015 release, a part of runtime library was extracted
and now comes with Windows Kits. This patch enables clang to use
Universal CRT library if %INCLUDE or %LIB environment varaibles are not
specified.
See also https://llvm.org/bugs/show_bug.cgi?id=24741
Patch by Igor Kudrin
Reviewers: zturner, hans, rnk
Subscribers: ruiu, cfe-commits
Differential Revision: http://reviews.llvm.org/D12695
llvm-svn: 247362
If target supports TLS all threadprivates are generated as TLS. If target does not support TLS, use runtime calls for proper codegen of threadprivate variables.
llvm-svn: 247273
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.
Differential Revision: http://reviews.llvm.org/D11857
llvm-svn: 247238
Seems it broke the Polly build.
From http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-fast/builds/11687/steps/compile/logs/stdio:
In file included from /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/lib/TableGen/Record.cpp:14:0:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:369:3: error: looser throw specifier for 'virtual llvm::TypedInit::~TypedInit()'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:270:11: error: overriding 'virtual llvm::Init::~Init() noexcept (true)'
llvm-svn: 247222
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
Summary: The command line options for these are -Wa,--trap and -Wa,--break.
Patch by Scott Egerton.
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11676
llvm-svn: 246765
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
Summary:
Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.
Introduce a frontend option -fdepfile-entry, and only insert them
for the user-defined sanitizer blacklists. In frontend, grab ExtraDeps
from -fdepfile-entry, instead of -fsanitize-blacklist.
Reviewers: rsmith, pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12544
llvm-svn: 246700
This patch refactors the code to use the GCC installation detector
(modified so that it works in Solaris), and uses
ToolChain::GetFilePath everywhere once it works.
Patch by Xan López <xan@igalia.com>!
llvm-svn: 246473
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.
llvm-svn: 246375
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
llvm-svn: 246192
Current implementation tries to guess which Action will result in a
job which needs to incorporate device-side GPU binaries. The guessing
was attempting to work around the fact that multiple actions may be
combined into a single compiler invocation. If CudaHostAction ends up
being combined (and thus bypassed during action list traversal) no
device-side actions it pointed to were processed. The guessing worked
for most of the usual cases, but fell apart when external assembler
was used.
This change removes the guessing and makes sure we create and pass
device-side jobs regardless of how the jobs get combined.
* CudaHostAction is always inserted either at Compile phase or the
FinalPhase of current compilation, whichever happens first.
* If selectToolForJob combines CudaHostAction with other actions, it
passes info about CudaHostAction up to the caller
* When it sees that CudaHostAction got combined with other actions
(and hence will never be passed to BuildJobsForActions),
BuildJobsForActions creates device-side jobs the same way they would
be created if CudaHostAction was passed to BuildJobsForActions
directly.
* Added two more test cases to make sure GPU binaries are passed to
correct jobs.
Differential Revision: http://reviews.llvm.org/D11280
llvm-svn: 246174
Error out if -mfloat-abi=hard or -mhard-float is specified on the command
line and the target ABI is APCS. Previously clang issued no warnings or
errors and just passed the option to the backend, which had no effect on
code generation for targets using APCS.
This commit corrects the patch commited in r245866, which didn't take into
account the fact that not all darwin targets use APCS.
rdar://problem/22257950
http://reviews.llvm.org/D12344
llvm-svn: 246054
Summary:
This is more consistent with other targets and also makes the -fuse-ld
flag work.
Reviewers: jvoung
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10697
llvm-svn: 245908
Error out if the user tries to use float-abi="hard" since it isn't
supported on darwin platforms. Previously clang issued no warnings or
erros and just passed the option to the backend, which had no effect on
code generation for targets using apcs.
rdar://problem/22257950
Differential Revision: http://reviews.llvm.org/D12155
llvm-svn: 245866
For some reason, clang had been treating a command like:
clang -static -fPIC foo.c
as if it should be compiled without the PIC relocation model.
This was incorrect: -static should be affecting only the linking
model, and -fPIC only the compilation.
This new behavior also matches GCC.
This is a follow-up from a review comment on r245447.
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245667
doing assembly-only, and unify the Driver's PIC argument parsing.
On a few architectures, parsing of assembly files annoyingly depends
on whether PIC is enabled or not. This was handled for external 'as'
already (passing -KPIC), but was missed for calls to the standalone
internal assembler.
The integrated-as.s test needed to be modified to not expect
-fsanitize=address to be unused, as now fsanitize *IS* used for
assembly, since -fsanitize=memory can sometimes imply -fPIE, which the
assembler needs to know (gack!!).
Differential Revision: http://reviews.llvm.org/D11845
llvm-svn: 245447
"generic" cpu was wrongly handled as exact real CPU name of ARMv8.1A architecture.
This has been fixed, now it is abstract name, suitable for any arch.
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11640
llvm-svn: 245445
Adds libomp.lib for -fopenmp=libomp and libiomp5md.lib for -fopenmp=libiomp5 on Windows
Differential Revision: http://reviews.llvm.org/D11932
llvm-svn: 245414
Summary:
When we want to use mingw-w64 and clang with compiler-rt we should not
need to have libgcc installed. This fixes finding includes when libgcc
is not installed
Reviewers: yaron.keren
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11808
llvm-svn: 244902
-mkernel enables -fno-builtin and -fno-common by default, but allows -fbuiltin
and -fcommon to override that. However "-fbuiltin -fno-builtin" is treated the
same as "-fbuiltin" which is wrong, so fix that. Also fixes similar behaviour
when -fno-common is default.
Differential Revision: http://reviews.llvm.org/D11459
llvm-svn: 244437
Implemented in MinGW::Linker::AddLibGCC since AddLibgcc is a logic puzzle even
before adding one more boolean. A first step towards simplification of AddLibgcc
would be to factor out the Android AddLibgcc code into its own routine.
llvm-svn: 244407
This patch adds flags -fno-profile-instr-generate and
-fno-profile-instr-use, and the GCC aliases -fno-profile-generate and
-fno-profile-use.
These flags are used in situations where users need to disable profile
generation or use for specific files in a build, without affecting other
files.
llvm-svn: 244153
Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
llvm-svn: 244097
This seems preferable to printing two warnings per unsupported option-
one warning about not supporting it, and one about not using it.
It also makes the '-Wno-' option do what you mean.
Differential Revision: http://reviews.llvm.org/D11766
llvm-svn: 244079
noticed until now.
The code for setting up the driver's InstalledDir didn't respect
-no-canonical-prefixes. Because of this, there are a few places in the
driver where we would unexpectedly form absolute paths, notably when
searching for and finding GCC installations to use, etc. The fix is
straightforward, and I've added this path to '-v' both so we can test it
sanely and so that it will be substantially more obvious the next time
someone has to debug something here.
Note that there is another bug that we don't actually *canonicalize* the
installed directory! I don't really want to fix that because I don't
have a realistic way to test the usage of this mode. I suspect that
folks using the shared module cache would care about getting this right
though, and so they might want to address it. I've left the appropriate
FIXMEs so that it is clear what to change, and I've updated the test
code to make it clear what is happening here.
llvm-svn: 244065
It doesn't make any sense to enable -gmlt with -gsplit-dwarf, since
-gmlt is designed for on-line symbolication (and -gsplit-dwarf normally
emits all the -gmlt data into the .o anyway - so there's nothing to
split out except redundant/duplicate info).
With this change they override each other, -gmlt -gsplit-dwarf is the
same as -gsplit-dwarf and -gsplit-dwarf -gmlt is the same as -gmlt.
llvm-svn: 243694
Copying the already existing code for x86 to ARM to set the correct CPU
features when using -mcpu=native. We can already detect the CPU name
but we were not setting the correct feature bits.
Moving fpu/hwdiv down to make sure they override whatever we set the
default to be.
No tests because this is native detection, and not all ARM-enabled builds
will hapen at a specific CPU, or even ARM. I have tested locally and it
works as expected.
Fixes PR12794.
llvm-svn: 243656
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
This commit changes the driver to save subtarget feature "+strict-align"
to the IR instead of using backend option "aarch64-strict-align". This is
needed for LTO.
rdar://problem/21529937
llvm-svn: 243518
This commit changes the driver to save subtarget feature "+strict-align" to the
IR instead of using backend option "arm-strict-align". This is needed for LTO.
Also, move the logic in ARM backend that was deciding whether strict alignment
should be forced to the front-end.
rdar://problem/21529937
http://reviews.llvm.org/D11472
llvm-svn: 243489
Host-only cuda compilation does produce valid host object
file and in some cases users do want to proceed on to the linking phase.
The change removes special case that stopped compilation pipeline at
the Assembly phase. Device-side compilation is still stopped early
by the types::getCompilationPhases().
Differential Revision: http://reviews.llvm.org/D11573
llvm-svn: 243478
This will be used for old targets like Android that do not
support ELF TLS models.
Differential Revision: http://reviews.llvm.org/D10524
llvm-svn: 243441
This patch allows Clang to pass on -Wa,-mfpu, -Wa,-mhwdiv and
-Wa,-mcpu to the integrated assembler (via target-features), but
-march is still not being passed, but validated.
In case the command line has both -mxxx and -Wa,-mxxx, we warn
that the naked one will not be used in assembler mode.
llvm-svn: 243353
To be able to handle -Wa, options in the assembler (ClangAs), we need to
make the handling of options based on the value of the options, not direct
Arguments from the list, since the list is immutable.
No functional change in this patch, but this allows validating of -Wa,-mfpu
and friends in the same way we validate -mfpu and friends, *just* for the
assembler.
llvm-svn: 243352
Also rename XCore (the toolchain) to XCoreToolChain since XCore is
also a namespace for its tools.
Differential Revision: http://reviews.llvm.org/D10609
llvm-svn: 243279
Currently trigger to select hard-float linker is only based of -gnueabihf
appearing in target triplet, but we should also select it when hardfloat
is requested via cmdline.
Patch by Khem Raj.
llvm-svn: 243262
We had multiple bugs here:
- We didn't support multiple optimization options in one argument.
e.g. -O2y-
- We didn't correctly expand -O[12dx] to their respective options.
- We treated -O1 as clang -O1 instead of clang -Os.
- We treated -Ox as clang -O3 instead of clang -O2. In fact, cl's -Ox
option is *less* powerful than cl's -O2 option despite -Ox described
as "Full Optimization".
This fixes PR24003.
llvm-svn: 243261
option "-aarch64-reserve-x18".
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/D11462
llvm-svn: 243185
Address Richard Smith comments: remove the trailing seperator from the Arch
variable, implement six mingw_* trees under tools/clangtest/Driver/Inputs
and merge linux and Windows tests into a universal test that uses these trees.
llvm-svn: 243098
The flag allows users to specify that they do not want the object file
to have any implicit /defaultlib directives.
This fixes PR24236.
llvm-svn: 243097
Currently, for --rtlib=compiler-rt on GNU systems, we're assuming
that one has libgcc_s and libgcc_eh as low-level libraries, which
when used in conjunction with -lunwind or -lc++abi, breaks that
assumption.
My original fix was wrong, and this patch reverts it to prepare for
a new flag to choose the unwinder/C++ libraries. For the time being,
people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any
combination they need explicitly.
llvm-svn: 243025
Now clang should be able to use compiler-rt and libc++ on mingw.
Based on a patch by Martell Malone.
Differential Revision: http://reviews.llvm.org/D11237
llvm-svn: 242905
It should now support three mingw distributions running on Windows
and three Linux distributions. The include directories for each are
listed in the comments.
llvm-svn: 242766
option "-arm-reserve-r9".
This recommits r242736, which had to be reverted because the llvm-side
change that was committed in r242737 caused the number of subtarget
features to go over the limit of 64.
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/D11319
llvm-svn: 242755
r242737 caused builds to fail with the following error message, so I'm
reverting the clang side change too:
error:Too many subtarget features! Bump MAX_SUBTARGET_FEATURES.
llvm-svn: 242741
option "-arm-reserve-r9".
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/D11319
llvm-svn: 242736
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:
We can enable warnings after that -w, so the patch might not be 100%
correct.
The problem that triggered this is: we have some amount of tests that
expect 0 warnings (including unit tests for -w), but -w ends up not fully
silencing everything.
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11322
llvm-svn: 242606
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
We now use the sanitizer special case list to decide which types to blacklist.
We also support a special blacklist entry for types with a uuid attribute,
which are generally COM types whose virtual tables are defined externally.
Differential Revision: http://reviews.llvm.org/D11096
llvm-svn: 242286
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
We will still default to ld until such a time lld become a
stable release. lld supports arm NT under the machine name "thumb2pe".
http://reviews.llvm.org/D11088
Patch by Martell Malone
Reviewed by Reid Kleckner
llvm-svn: 242121
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
The function is massively large and GCC is emitting stack overflow
errors when building it (stack, as counted by the compiler, grows to
more than 16Kb).
The new flag processing logic added in r241825 took it over the limit.
llvm-svn: 241918
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
Until somebody writes the code for it, be loud about the fact that
it's not implemented yet.
Differential Revision: http://reviews.llvm.org/D11020
llvm-svn: 241708
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
The patch is the same except for the addition of a new test for the
issue that required reverting the dependent llvm commit.
--Original Commit Message--
Pass down the -flto option to the -cc1 job, and from there into the
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
llvm-svn: 241467
We had a strange relationship here where we made a list of Jobs
inherit from a single Job, but there weren't actually any places where
this arbitrary nesting was used or needed.
Simplify all of this by removing Job entirely and updating all of the
users to either work with a JobList or a single Command.
llvm-svn: 241310
No more hardcoded paths: clang will use -sysroot as gcc root location if
provided. Otherwise, it will search for gcc on the path. If not found it
will use the driver installed location.
http://reviews.llvm.org/D5268
Patch by Ruben Van Boxem, Martell Malone, Yaron Keren.
Reviewed by Reid Kleckner.
llvm-svn: 241241
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
- Hexagon options were physically next to to ones that had a
preceding comment saying "Double dash options", which they aren't.
- The 'ld' tool classes are named Linker, not Link.
llvm-svn: 240980
Nothing was hand edited afterward except a few literal strings
and comments that were poorly broken.
Differential Revision: http://reviews.llvm.org/D10689
llvm-svn: 240791
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:
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
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
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
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 causes programs compiled with this flag to print a diagnostic when
a control flow integrity check fails instead of aborting. Diagnostics are
printed using UBSan's runtime library.
The main motivation of this feature over -fsanitize=vptr is fidelity with
the -fsanitize=cfi implementation: the diagnostics are printed under exactly
the same conditions as those which would cause -fsanitize=cfi to abort the
program. This means that the same restrictions apply regarding compiling
all translation units with -fsanitize=cfi, cross-DSO virtual calls are
forbidden, etc.
Differential Revision: http://reviews.llvm.org/D10268
llvm-svn: 240109
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
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
llvm-svn: 239789
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
We were adding an extra "-mlinker-version" argument to the invocation
based on a value inferred from "ld -v". This is set by the build
systems to either a sane value or an empty string (e.g. for custom
built ld), which we don't want to pass on.
No test really possible because the value depends on both host system
and how CMake was invoked.
llvm-svn: 239633
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
Removed comment in Driver::ShouldUseClangCompiler implying that there
was an opt-out ability at that point - there isn't.
Differential Revision: http://reviews.llvm.org/D10246
llvm-svn: 239608
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
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
llvm-svn: 239481
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 the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
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
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
-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option that allows to override effect of -fopenmp and link libgomp library (if -fopenmp=libgomp is specified).
Differential Revision: http://reviews.llvm.org/D9736
llvm-svn: 237769
sys/time.h on Solaris (and possibly other systems) defines "SEC" as "1"
using a cpp macro. The result is that this fails to compile.
Fixes https://llvm.org/PR23482
llvm-svn: 237113
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
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
This change is the third of 3 patches to add support for specifying
the profile output from the command line via -fprofile-instr-generate=<path>,
where the specified output path/file will be overridden by the
LLVM_PROFILE_FILE environment variable.
This patch adds the necessary support to the clang frontend, and adds a
new test.
The compiler-rt and llvm parts are r236055 and r236288, respectively.
Patch by Teresa Johnson. Thanks!
llvm-svn: 236289
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
NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.
Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.
Differential Revision: http://reviews.llvm.org/D9260
llvm-svn: 235903
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
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
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
- Debian jessie will be released this month, add the next testing version to the list.
- RHEL7 was released last june.
- Ubuntu utopic was released last october, vivid will follow later this month.
llvm-svn: 234149
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
This is necessary because not aall Sandybridge, Ivybrige, Haswell, and Broadwell CPUs support AVX. Currently we modify the CPU name back to Nehalem for this case, but that turns off additional features for these CPUs.
llvm-svn: 233672
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
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
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
Reviewers: rsmith, rjmccall
Differential Revision: http://reviews.llvm.org/D8467
llvm-svn: 232788
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
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
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
With out this patch,
"clang -help" prints "USAGE: clang-3 [options] <inputs>".
It should either print
USAGE: clang [options] <inputs>
or
USAGE: clang-3.7 [options] <inputs>
With this patch, on Linux, it prints
USAGE: clang-3.7 [options] <inputs>
On Windows, it prints
USAGE: clang.exe [options] <inputs>
llvm-svn: 231124
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
As Chandler responded on the initial commit, just directly setting the
triple through -Xclang option to the driver creates havoc on other
platforms. The driver test should specifically go into test/Driver and
test the cc1 commandline itself.
llvm-svn: 231063
This adds the -fapplication-extension option, along with the
ios_app_extension and macosx_app_extension availability attributes.
Patch by Ted Kremenek
llvm-svn: 230989
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
Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
llvm-svn: 230587
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
If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.
llvm-svn: 230006
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
What's going on here is that the ternary operator produces a std::string rvalue
that the StringRef points to. I'd hoped bugs like this were a thing of the past
with our asan testing but apparently this code path is only used when LLVM is
configured with a custom --with-c-include-dirs setting.
Unbreaks bootstrapping with GCC5 on Fedora (PR22625), patch by Jonathan Wakely!
llvm-svn: 229719
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
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
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
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
Previously, we would use a frame pointer by default on non-Linux OSs. On
Linux, any optimization flags imply -fomit-frame-pointer. XCore always
defaulted to -fomit-frame-pointer.
Now x86 Windows matches our behavior on Linux. All other ISAs supported
by Windows (ARM, x64) use xdata information, and frame pointers aren't
useful. Frame pointers are now off by default for such targets, but can
be forced via -fno-omit-frame-pointer and code using alloca().
In fact, on Win64 our frame-pointer prologue is not describable with
UNWIND_INFO. This change is a workaround to avoid using the broken FP
using prologue for most functions. This is PR22467.
llvm-svn: 228236
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
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
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
A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.
Command line options:
-noop-insertion // Enable noop insertion.
-noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
-max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.
In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
-fdiversify
This is the clang part of the patch.
llvm part: D3392
http://reviews.llvm.org/D3393
Patch by Stephen Crane (@rinon)
llvm-svn: 225910
Introduce the following -fsanitize-recover flags:
- -fsanitize-recover=<list>: Enable recovery for selected checks or
group of checks. It is forbidden to explicitly list unrecoverable
sanitizers here (that is, "address", "unreachable", "return").
- -fno-sanitize-recover=<list>: Disable recovery for selected checks or
group of checks.
- -f(no-)?sanitize-recover is now a synonym for
-f(no-)?sanitize-recover=undefined,integer and will soon be deprecated.
These flags are parsed left to right, and mask of "recoverable"
sanitizer is updated accordingly, much like what we do for -fsanitize= flags.
-fsanitize= and -fsanitize-recover= flag families are independent.
CodeGen change: If there is a single UBSan handler function, responsible
for implementing multiple checks, which have different recoverable setting,
then we emit two handler calls instead of one:
the first one for the set of "unrecoverable" checks, another one - for
set of "recoverable" checks. If all checks implemented by a handler have the
same recoverability setting, then the generated code will be the same.
llvm-svn: 225719
The rewrite map files are not copied, and so cannot be tracked as temporary
files. Add them explicitly to the list of files that we request from the user
to be attached to bug reports.
llvm-svn: 225614
It seemed odd to have to make DefaultImageName be a mutable member of Driver.
We don't need to the full result of computeTargetTriple() to determine the
image name; just base it on DefaultTargetTriple.
llvm-svn: 225530
Allow blessed access to the symbol rewriter from the driver. Although the
symbol rewriter could be invoked through tools like opt and llc, it would not
accessible from the frontend. This allows us to read the rewrite map files in
the frontend rather than the backend and enable symbol rewriting for actually
performing the symbol interpositioning.
llvm-svn: 225504
Summary:
Allow -fsanitize-coverage=N with ubsan, clang part.
This simply allows the flag combination.
The LLVM will work out of the box, the compile-rt part
will follow as a separate patch.
Test Plan: check-clang
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6849
llvm-svn: 225229
It is somewhat common for CFLAGS to be used with .s files. We were
already ignoring -flto. This patch just does the same for -fno-lto.
llvm-svn: 225093
Unfortunately, MSVC does not indicate to the driver what target is being used.
This means that we cannot correctly select the target architecture for the
clang_rt component. This breaks down when targeting windows with the clang
driver as opposed to the clang-cl driver. This should fix the native ARM
buildbot tests.
llvm-svn: 225089
The logic for addSanitizerRTWindows was performing the same logical operation as
getCompilerRT, which was previously fully generalised for Linux and Windows.
This avoids having a duplication of the logic for building up the name of a
clang_rt component. This change does move the current limitation for Windows
into getArchNameForCompilerRTLib, where it is assumed that the architecture for
Windows is always i386.
llvm-svn: 225087
Unify the component handling for compiler-rt. The components are regularly
named, built up from:
${LIBRARY_PREFIX}clang_rt.${component}-${arch}[-${environment}]${LIBRARY_SUFFIX}
Unify the handling for all the various components, into a single path to link
against the various components in a number of places. This reduces duplication
of the clang_rt library name construction logic.
llvm-svn: 225013
Unlike Unices, Windows does not use a library prefix. Use the traditional
naming scheme even for Windows itanium environments. This makes the builtins
behave more like the sanitisers as well.
llvm-svn: 224996
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.
Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.
This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.
I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.
Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.
llvm-svn: 224924
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
llvm-svn: 224790
This reapplies r224503 along with a fix for compiling Fortran by having the
clang driver invoke gcc (see r224546, where it was reverted). I have added
a testcase for that as well.
Original commit message:
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
llvm-svn: 224688
Summary:
This patch adds "all" sanitizer group. A shortcut "-fno-sanitize=all"
can be used to disable all sanitizers for a given source file.
"-fsanitize=all" option makes no sense, and will produce an error.
This group can also be useful when we add "-fsanitize-recover=<list>"
options (patch in http://reviews.llvm.org/D6302), as it would allow
to conveniently enable/disable recovery for all specified sanitizers.
Test Plan: regression test suite
Reviewers: kcc, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6733
llvm-svn: 224596
This reverts commit r224503.
It broke compilation of fortran through the Clang driver. Previously
`clang -c t.f` would invoke `gcc t.f` and `clang -cc1as`, but now it
tries to call `clang -cc1 t.f` which fails for obvious reasons.
llvm-svn: 224546
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
llvm-svn: 224503
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
llvm-svn: 224375
can change the backend to be the same default. Leave the
modified/new testcases with the exception of the default behavior
since it increases our testing footprint.
llvm-svn: 223976
This reverts commit r223455. It's been succesfully argued that
-fexceptions (at the driver level) is a misnomer and has little to do
with -fobjc-exceptions.
llvm-svn: 223723
Clang attempted to replicate a GCC bug: -fobjc-exceptions forces
-fexceptions to be enabled. However, this has unintended effects and
other awkard side effects that Clang doesn't "correctly" ape (e.g. it's
impossible to turn off C++ exceptions in ObjC++ mode).
Instead, -f[no]objc-exceptions and -f[no]cxx-exceptions now have an
identical relationship with -f[no]exceptions.
llvm-svn: 223455
No functionality change is intended, just a cleanup of the logic clang
uses to determine what -fexceptions/-fno-exceptions ends up doing.
llvm-svn: 223453
I added this check a while back but then made a note to myself that it
should be completely unnecessary since iOS always uses PIC code-gen for
aarch64. Since I could never come up with any reason why it would be
necessary, I'm just going to remove it and we'll see if anything breaks.
rdar://problem/13627985
llvm-svn: 223097
Using lld on Windows requires calling link-lld.exe instead of
lld.exe. This patch puts this knowledge into clang so that when
using the GCC style clang driver, it can properly delegate to
lld.
Differential Revision: http://reviews.llvm.org/D6428
Reviewed by: Reid Kleckner, Rui Ueyama
llvm-svn: 223086
Add neon-vfpv3 to allow specifying both at the same time. This is not an
option that GCC supports, but follows the same track and should be
non-controversial.
Change-Id: Id9ec157c835937d7d11ad0f49dbe5171fac17658
llvm-svn: 222933
Revision 220571 removes the requirement to use -pie for tsan binaries. So remove -pie from driver.
Also s/hasZeroBaseShadow/requiresPIE/ because that is what it is used for. Msan does not have zero-based shadow, but requires pie. And in general the relation between zero-based shadow and pie is unclear.
http://reviews.llvm.org/D6318
llvm-svn: 222526
When it's used without an argument, the default file name is
used. The same goes for /Fe.
Also, allow using /Fo, /Fa and /Fe with multiple inputs if they
don't have an argument.
llvm-svn: 222164
In particular, make SanitizerArgs responsible for parsing
and passing down to frontend -fsanitize-recover and
-fsanitize-undefined-trap-on-error flags.
Simplify parsing -f(no-)sanitize= flags parsing: get rid of
too complex filterUnsupportedKinds function.
No functionality change.
llvm-svn: 222105
Remove flag parsing details from the public header.
Use SanitizerSet to represent the set of enabled sanitizers.
Cleanup the implementation: update the comments to
reflect reality, remove dead code.
No functionality change.
llvm-svn: 221968
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
This change removes libclang_rt.profile-pic-<arch>.a version of
profile runtime. Instead, it's sufficient to always build
libclang_rt.profile-<arch>.a with -fPIC, as it can be linked into
both executables and shared objects.
llvm-svn: 221952
Summary:
This change makes the asan-coverge (formerly -mllvm -asan-coverge)
accessible via a clang flag.
Companion patch to LLVM is http://reviews.llvm.org/D6152
Test Plan: regression tests, chromium
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6153
llvm-svn: 221719
Darwin's "-arch arm64" option implies full Cyclone CPU, for both architectural
and tuning purposes. So if neither of the explicit options have been given,
forward that on to the proper invocation.
rdar://problem/18906227
llvm-svn: 221631
If clang was configured with a custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the equivalent configure command), the path to the custom gcc toolchain path takes precedence to the one specified by -ccc-install-dir. This causes several regression tests to fail as they will be using an unexpected path. Adding the switch --gcc-toolchain="" in each test command is not enough as the hexagon toolchain implementation in the driver is not evaluating this argument. This commit modifies the hexagon toolchain to take the --gcc-toolchain="" argument into account when deciding the toolchain path, similarly to what is already done for other targets toolchains. Additionally, the faulty regression tests are modified in order to --gcc-toolchain="" be passed to the commands.
llvm-svn: 221535
This CPU definition is redundant. The Cortex-A9 is defined as
supporting multiprocessing extensions. Remove references to this CPU.
This CPU was recently removed from LLVM. See http://reviews.llvm.org/D6057
Change-Id: I62ae7cc656fcae54fbaefc4b6976e77e694a8678
llvm-svn: 221458
The command line options are specified in a space-separated list that is an
argument to -dwarf-debug-flags, so that breaks if there are spaces in the
options. This feature came from Apple's internal version of GCC, so I went back
to check how llvm-gcc handled this and matched that behavior.
rdar://problem/18775420
llvm-svn: 221309
Change the LC_ID_DYLIB of ASan's dynamic libraries on OS X to be set to "@rpath/libclang_rt.asan_osx_dynamic.dylib" and similarly for iossim. Clang driver then sets the "-rpath" to be the real path to where clang currently has the dylib (because clang uses the relative path to its current executable). This means if you move the compiler or install the binary release, -fsanitize=address will link to the proper library.
Reviewed at http://reviews.llvm.org/D6018
llvm-svn: 221279
The former name doesn't make sense, we are using this parameter for both .a and .dylib libraries.
No functional change.
http://reviews.llvm.org/D6040
llvm-svn: 220939
Rather than asserting that the target is unsupported, make a guess at what the
tree for a port would look like and use that for the search path.
Addresses review comments from Ried Kleckner for SVN r220547.
llvm-svn: 220624
'char' is unsigned on all ARM and Thumb architectures. Clang gets this
right for ARM, and for thumb when using and arm triple and the -mthumb
option, but gets it wrong for thumb triples. This fixes that.
llvm-svn: 220555
This is a very basic toolchain. It supports cross-compiling Windows (primarily
inspired by the WoA target). It is meant to use clang with the LLVM IAS and a
binutils ld-compatible interface for the linker (eventually to be lld). It does
not perform any "standard" GCC lookup, nor does it perform any special
adjustments given that it is expected to be used in an environment where the
user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK.
The primary runtime library is expected to be compiler-rt and the C++
implementation to be libc++.
It also expects that a sysroot has been setup given the usual Unix semantics
(standard C headers in /usr/include, all the import libraries available in
/usr/lib). It also expects that an entry point stub is present in /usr/lib
(crtbegin.obj for executables, crtbeginS.obj for shared libraries).
The entry point stub is responsible for running any GNU constructors.
llvm-svn: 220546
This is a sad thing to do, but all the alternatives look ugly.
Looks like there are legitimate cases when users may want to link
with sanitizer runtimes *and* -nodefaultlibs (and ensure they provide
replacements for system libraries). For example, this happens in libc++
test suite.
"-nodefaultlibs" is told to link only the libraries explicitly provided
by the user, and providing "-fsanitize=address" is a clear indication of
intention to link with ASan runtime.
We can't easily introduce analogue of "-print-libgcc-name": linking with
sanitizers runtimes is not trivial: some runtimes are split into several
archive libraries, which are required to be wrapped in
-whole-archive/-no-whole-archive.
If "-fsanitize=whatever" and "-nodefaultlibs" are provided, system library
dependencies of sanitizer runtimes (-lc/-ldl/-lpthread/-lrt) will *not* be
linked, and user would have to link them in manually. Note that this can
cause problems, as failing to provide "-lrt" might lead to crashes in runtime
during ASan initialization. But looks like we should bite this bullet.
See r218541 review thread for the discussion.
llvm-svn: 220455
When a user has not configured a standard Visual Studio environment
by running vcvarsall, clang tries its best to find Visual Studio
include files and executables anyway. This patch makes clang also
try to find system and Windows SDK libraries for linking against,
as well.
Reviewed by: Hans Wennborg
Differential Revision: http://reviews.llvm.org/D5873
llvm-svn: 220425
This resubmits change r220226. That change broke the chromium
build bots because chromium it ships an hermetic MSVC toolchain
that it expects clang to fallback to by finding it on the path.
This patch fixes the issue by bumping up the prioritization of PATH
when looking for MSVC binaries.
Reviewed by: Hans Wennborg, Reid Kleckner
Differential Revision: http://reviews.llvm.org/D5892
llvm-svn: 220424
This renames the Windows toolchain to MSVCToolChain. This is a preparatory step
for adding a CrossWindowsToolChain which uses clang/libc++/(ld/lld) without the
standard GCC toolchain lookup. NFC.
llvm-svn: 220362
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
-g1 on gcc (and also IBM's xlc) are documented to be very similar to
-gline-tables-only. Our -gline-tables-only might still be more verbose than -g1
on other compilers, but currently we treat -g1 as -g, and so we're producing
much more debug info at -g1 than everybody else. Treating -g1 as
-gline-tables-only brings us much closer to what everyone else is doing.
For more information, see the discussion on
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039649.html
llvm-svn: 220311
This fixes crash report generation when filenames have spaces. It also
removes an awkward workaround that quoted *some* arguments when
generating crash reports.
llvm-svn: 220307
This pushes the logic for generating a crash reproduction script
entirely into Command::Print, instead of Command doing half of the
work and then relying on textual substitution for the rest. This makes
this logic much easier to read and will simplify fixing a couple of
issues in this area.
llvm-svn: 220305
In environments where PATH was set to point to the VS installation, Clang would
override that by looking in the registry and finding the latest VS installation.
If the environment is set up to point to a VS installation, that should take
precedence.
Reverting this until we can fix it.
llvm-svn: 220243
List the module cache we use for crashdumps as a tempfile. This
simplifies how we pick up this directory when generating the actual
crash diagnostic and removes some duplicate logic.
llvm-svn: 220241
In practice there's only ever one temporary output file when
generating a crashdump, but even if there were many iterating over
each and creating a duplicate run script for each one wouldn't make
very much sense.
This updates the behaviour to only generate the script once, based on
the first filename.
This should make it more reasonable to generate extra output files to
include in the crashdump going forward, so I've also added a FIXME to
look into doing just that with the extra module crashdump files.
llvm-svn: 220238
We currently use a null FailingCommand when generating crash reports
as an indication that the cause is FORCE_CLANG_DIAGNOSTICS_CRASH, the
environment variable that exists to test crash dumps. This means that
our tests don't actually cover real crashes at all, and adds a more
complicated code path that's only used in the tests.
Instead, we can have the driver synthesize that every command failed
and just call generateCompilationDiagnostics normally.
llvm-svn: 220234
Typically clang finds Visual Studio by the user explicitly setting
up a Visual Studio environment via vcvarsall. But we still try to
behave intelligently and fallback to different methods of finding
Visual Studio when this is not done. This patch improves various
fallback codepaths to make Visual Studio locating more robust.
Specifically, this patch:
* Adds support for searching environment variables for VS 12.0
* Correctly locates include folders for Windows SDK 8.x (this was
previously broken, and would cause clang to error)
* Prefers locating link.exe in the same location as cl.exe. This
is helpful in case another link.exe is in the path earlier than
Visual Studio (e.g. GnuWin32)
* Minor cleanup in the registry reading code to make it more
robust in the presence of long pathnames.
llvm-svn: 220226
Summary:
AddressSanitizer currently doesn't support this configuration, and binaries
built with it will just get into an infinite loop during startup.
Test Plan: Includes an automated test.
Reviewers: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5764
llvm-svn: 219744
Some early revisions of the Cortex-A53 have an erratum (835769) whereby it is
possible for a 64-bit multiply-accumulate instruction in AArch64 state to
generate an incorrect result. The details are quite complex and hard to
determine statically, since branches in the code may exist in some
circumstances, but all cases end with a memory (load, store, or prefetch)
instruction followed immediately by the multiply-accumulate operation.
The safest work-around for this issue is to make the compiler avoid emitting
multiply-accumulate instructions immediately after memory instructions and the
simplest way to do this is to insert a NOP.
This patch implements clang options to enable this workaround in the backend.
The work-around code generation is not enabled by default.
llvm-svn: 219604
We can safely rely on the architecture to distinguish iOS device builds from
iOS simulator builds. We already have code to do that, in fact. This simplifies
some of the error checking for the option handling.
llvm-svn: 219545
This was previously only used when explicitly requested with a command line
option because it had to work with some old versions of the linker when it
was first introduced. That is ancient history now, and it should be safe to
use the correct option even when using the IPHONEOS_DEPLOYMENT_TARGET
environment variable to specify that the target is the iOS simulator.
Besides updating the test for this, I also added a few more tests for the
iOS linker options.
llvm-svn: 219527
It turns out that this was never used. Instead we just use the
IPHONEOS_DEPLOYMENT_TARGET variable for both iOS devices and simulator.
rdar://problem/18596744
llvm-svn: 219467
Looks like llvm::sys::path::filename() was canonicalizing my paths
before emitting them for FileCheck to stumble over.
Fix a style nit with r219460 while I'm at it.
llvm-svn: 219464
When building with coverage, -no-integrated-as, and -c, the driver was
emitting -cc1 -coverage-file pointing at a file in /tmp. Ensure the
coverage file is emitted in the same directory as the output file.
llvm-svn: 219460
Summary:
This change adds an experimental flag -fsanitize-address-field-padding=N (0, 1, 2)
to clang and driver. With this flag ASAN will be able to detect some cases of
intra-object-overflow bugs,
see https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
There is no actual functionality here yet, just the flag parsing.
The functionality is being reviewed at http://reviews.llvm.org/D5687
Test Plan: Build and run SPEC, LLVM Bootstrap, Chrome with this flag.
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5676
llvm-svn: 219417
Summary: The changes introduced in the above two commits are giving
a rough time to one of the build bots. Reverting the changes for the
moment so that the bot can go green again.
Change-Id: Id19f6cb2a8bc292631fac2262268927563d820c2
llvm-svn: 218970
There's probably never a good reason to iterate over unique_ptrs. This
lets us use range-for and say Job.foo instead of (*it)->foo in a few
places.
llvm-svn: 218938
The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.
llvm-svn: 218748
Dan Gohman