This flag isn't needed, or permitted, with the "ld" flavor of lld.
Also, add a basic ld commandline test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256216 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256204 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256104 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256026 91177308-0d34-0410-b5e6-96231b3b80d8
".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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255814 91177308-0d34-0410-b5e6-96231b3b80d8
Split the CFI runtime in two: cfi and cfi_diag. The latter includes
UBSan runtime to allow printing diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255736 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255694 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255515 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255502 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254927 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254535 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254161 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254160 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253886 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253846 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253813 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to construct Linux toolchains without a valid linker. This
is needed for example to build a CUDA device toolchain after r253385.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253707 91177308-0d34-0410-b5e6-96231b3b80d8
The patch expanded the flag *at the end*, breaking invocations like:
clang-cl /W4 -Wno-unused-parameter
Reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253678 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253389 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253386 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253385 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252901 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252571 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252545 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252463 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251708 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251706 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r251633. I'll investigate the test failure off trunk in
order to keep the buildbots clean.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251698 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251696 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251695 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251633 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251430 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251041 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250994 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250657 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250455 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250402 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250398 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250293 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250262 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the default of 3 hidden in the assembler previously.
Fixes breakage caused by r249655, reported by vsukharev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250173 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250094 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249704 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249655 91177308-0d34-0410-b5e6-96231b3b80d8
There are still some loose ends here but it's sufficient so we can detect
GCC headers that are inside of a VFS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249556 91177308-0d34-0410-b5e6-96231b3b80d8
There are two remaining buildbot failures that we'll have to
investigate before submitting this again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249298 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249294 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249279 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249227 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249143 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249137 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249030 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248932 91177308-0d34-0410-b5e6-96231b3b80d8
* assembling from a .s file mistook -ggdb0 for -g
* -ggdb1 is supposed to mean basically -g1, not -gN for N>1
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248912 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248649 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248496 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248481 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248378 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248095 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248094 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248083 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247967 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247634 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247603 91177308-0d34-0410-b5e6-96231b3b80d8
-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247451 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247362 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247273 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246814 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246764 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246760 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246755 91177308-0d34-0410-b5e6-96231b3b80d8
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>!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246473 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246375 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246192 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246054 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245866 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245667 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245447 91177308-0d34-0410-b5e6-96231b3b80d8
"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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245445 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed to prevent breakage of -Wl,-as-needed link when
interceptors for functions in libutil are added. See PR15823.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245344 91177308-0d34-0410-b5e6-96231b3b80d8
-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244437 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244407 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244153 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244097 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244079 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243694 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243656 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243642 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243518 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243489 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243353 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243352 91177308-0d34-0410-b5e6-96231b3b80d8
After r243308, the front-end is responsible for checking the target OS and
passing reserve-x18 if the target is Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243310 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243262 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243261 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243185 91177308-0d34-0410-b5e6-96231b3b80d8
The flag allows users to specify that they do not want the object file
to have any implicit /defaultlib directives.
This fixes PR24236.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243097 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243025 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242755 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242741 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242736 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242565 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242504 91177308-0d34-0410-b5e6-96231b3b80d8
"-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242368 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242176 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242085 91177308-0d34-0410-b5e6-96231b3b80d8
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."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242077 91177308-0d34-0410-b5e6-96231b3b80d8
- 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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242058 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241952 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241925 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241918 91177308-0d34-0410-b5e6-96231b3b80d8
In certain builds (msan), this can otherwise exceed the stack frame
limit set for certain environments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241894 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241825 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241678 91177308-0d34-0410-b5e6-96231b3b80d8
"-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241565 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241467 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241241 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241225 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241077 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240980 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240455 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240170 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240134 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240019 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239818 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239789 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239762 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239755 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239619 91177308-0d34-0410-b5e6-96231b3b80d8
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -march option for ARM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239527 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239481 91177308-0d34-0410-b5e6-96231b3b80d8
Encoding the version into the triple will allow us to communicate to
LLVM what functions it can expect to depend upon in the implementation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239273 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239152 91177308-0d34-0410-b5e6-96231b3b80d8
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239059 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238601 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238389 91177308-0d34-0410-b5e6-96231b3b80d8
Now that ARMTargetParser can parse profile and version numbers,
use them instead of the local implementation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238037 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237894 91177308-0d34-0410-b5e6-96231b3b80d8
configurable in the CMake build. There shouldn't be any change in default
behavior.
Derived from a patch by Daniel Jasper!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237850 91177308-0d34-0410-b5e6-96231b3b80d8
-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237769 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237074 91177308-0d34-0410-b5e6-96231b3b80d8
This patch factor out the code in hexagon::Link::ConstructJob to be reused
in other functions. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236926 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236901 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236859 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236846 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236531 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236289 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235924 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235903 91177308-0d34-0410-b5e6-96231b3b80d8
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`).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234962 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234920 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234882 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234668 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234661 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234493 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234488 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234143 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234101 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233860 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233804 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233672 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233594 91177308-0d34-0410-b5e6-96231b3b80d8
Dan Gohman