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
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@233393 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233299 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233269 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233010 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232906 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232788 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232622 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232469 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231960 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231559 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231091 91177308-0d34-0410-b5e6-96231b3b80d8
recognition of mernizer's -objcmt-migrate-property-dot-syntax
option with a new test in test/Driver. rdar://19994452
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231080 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231063 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the -fapplication-extension option, along with the
ios_app_extension and macosx_app_extension availability attributes.
Patch by Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230989 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230587 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230243 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230055 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230031 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230006 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229801 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229661 91177308-0d34-0410-b5e6-96231b3b80d8
The current implementation causes link-time ODR violations when the delete symbols are exported into the dynamic table.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229241 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229082 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228413 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228329 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228253 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228236 91177308-0d34-0410-b5e6-96231b3b80d8
A previous commit added Cortex-A72 to LLVM, this teaches Clang to
accept it as well.
Patch by Ranjeet Singh.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228141 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228013 91177308-0d34-0410-b5e6-96231b3b80d8
-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227886 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227518 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227393 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227392 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227062 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226340 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225910 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225504 91177308-0d34-0410-b5e6-96231b3b80d8
On OS X a .s file is preprocessed, it is not on linux, which is why the warning was still
showing up on linux but not OS X.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225095 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225093 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225089 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225087 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225013 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224996 91177308-0d34-0410-b5e6-96231b3b80d8
The differences are pretty superficial:
- .lib vs .a extensions
- whether or not to link (potentially) incorrectly against libgcc_s
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224975 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224790 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224688 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224546 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224503 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224375 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223976 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223723 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223455 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality change is intended, just a cleanup of the logic clang
uses to determine what -fexceptions/-fno-exceptions ends up doing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223453 91177308-0d34-0410-b5e6-96231b3b80d8
Eugene Zelenko