Add Tool and ToolChain support for clang to target the NaCl OS using the NaCl
SDK for x86-32, x86-64 and ARM.
Includes nacltools::Assemble and Link which are derived from gnutools. They
are similar to Linux but different enought that they warrant their own class.
Also includes a NaCl_TC in ToolChains derived from Generic_ELF with library
and include paths suitable for an SDK and independent of the system tools.
Differential Revision: http://reviews.llvm.org/D8590
llvm-svn: 233594
Like on other 64-bit platforms, Int64Type should be SignedLong
on SystemZ, not SignedLongLong as per default. This could cause
ABI incompatibilities in certain cases (e.g. name mangling).
llvm-svn: 233544
they enable/disable.
This fixes two things:
a) sse4 isn't actually a target feature, don't treat it as one.
b) we weren't correctly disabling sse4.1 when we'd pass -mno-sse4
after enabling it, thus passing preprocessor directives and
(soon) passing the function attribute as well when we shouldn't.
llvm-svn: 233223
This patch adds Hardware Transaction Memory (HTM) support supported by ISA 2.07
(POWER8). The intrinsic support is based on GCC one [1], with both 'PowerPC HTM
Low Level Built-in Functions' and 'PowerPC HTM High Level Inline Functions'
implemented.
Along with builtins a new driver switch is added to enable/disable HTM
instruction support (-mhtm) and a header with common definitions (mostly to
parse the TFHAR register value). The HTM switch also sets a preprocessor builtin
HTM.
The HTM usage requires a recently newer kernel with PPC HTM enabled. Tested on
powerpc64 and powerpc64le.
This is send along a llvm patch to enabled the builtins and option switch.
[1]
https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Hardware-Transactional-Memory-Built-in-Functions.html
Phabricator Review: http://reviews.llvm.org/D8248
llvm-svn: 233205
On android x86_32 the long double is only 64 bits (compared to 80 bits
on linux x86_32) and on android x86_64 the long double is IEEEquad
(compared to x87DoubleExtended on linux x86_64). This CL creates new
TargetInfo classes for this targets to represent these differences.
Differential revision: http://reviews.llvm.org/D8357
llvm-svn: 233177
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
N.B. CodeGen support is still ongoing.
llvm-svn: 232906
OpenCL C Spec v2.0 Section 6.13.11
- Made c11 _Atomic being not accepted for OpenCL
- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef
- Added diagnostics for atomics Khronos extension enabling
llvm-svn: 232631
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
We disabled support for _Atomic because the STL had name conflicts,
they've been resolved in 2015. Similarly, reenable char16_t and
char32_t.
llvm-svn: 232611
ARMv6K is another layer between ARMV6 and ARMV6T2. This is the Clang
side of the changes.
ARMV6 family LLVM implementation.
+-------------------------------------+
| ARMV6 |
+----------------+--------------------+
| ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors
+----------------+--------------------+ have support for hint instructions
| ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can
+-------------------------------------+ be either real or default to NOP.
| ARMV7 (arm,thumb,thumb2) | The two processors also use
+-------------------------------------+ different encoding for them.
Patch by Vinicius Tinti.
llvm-svn: 232469
location data is available. If pragma handling wants to look up the
position, it finds the LLVM buffer and wants to compare it with the
special built-in buffer, failing badly. Extend to the special handling
of the built-in buffer to also check for the inline asm buffer. Expect
only a single asm buffer. Sort it between the built-in buffers and the
normal file buffers.
Fixes the assert part of PR 22576.
llvm-svn: 232389
Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.
llvm-svn: 231960
CloudABI can be identified by the __CloudABI__ preprocessor definition. The
system uses ELF executables.
CloudABI uses Unicode 7.0.0 for the encoding of wchar_t. As Unicode 7.0.0 is
synchronized with ISO/IEC 10646:2012 (released on 2012-06-01),
__STDC_ISO_10646__ is defined as 201206L.
llvm-svn: 231912
MSVC doesn't warn on this. Users are expected to apply the WINAPI macro
to functions passed by pointer to the Win32 API, and this macro expands
to __stdcall. This means we end up with a lot of useless noisy warnings
about ignored calling conventions when compiling code with clang for
Win64.
llvm-svn: 230668
Currently, the NaN values emitted for MIPS architectures do not cover
non-IEEE754-2008 compliant case. This change fixes the issue.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D7882
llvm-svn: 230653
The patch teaches the clang's driver to understand new MIPS ISA names,
pass appropriate options to the assembler, defines corresponding macros etc
http://reviews.llvm.org/D7737
llvm-svn: 230092
Add some of the missing M and R class Cortex CPUs, namely:
Cortex-M0+ (called Cortex-M0plus for GCC compatibility)
Cortex-M1
SC000
SC300
Cortex-R5
llvm-svn: 229661
For compatibility with GCC (and because it's generally helpful information
otherwise inaccessible to the preprocessor). This appears to be canonically the
alignment of max_align_t (e.g. on i386, __BIGGEST_ALIGNMENT__ is 4 even though
vector types will be given greater alignment).
Patch mostly by Mats Petersson
llvm-svn: 228367
Summary:
Allow user to provide multiple blacklists by passing several
-fsanitize-blacklist= options. These options now don't override
default blacklist from Clang resource directory, which is always
applied (which fixes PR22431).
-fno-sanitize-blacklist option now disables all blacklists that
were specified earlier in the command line (including the default
one).
This change depends on http://reviews.llvm.org/D7367.
Test Plan: regression test suite
Reviewers: timurrrr
Subscribers: cfe-commits, kcc, pcc
Differential Revision: http://reviews.llvm.org/D7368
llvm-svn: 228156
Summary:
It was used for interoperability with PNaCl's calling conventions, but
it's no longer needed.
Also Remove NaCl*ABIInfo which just existed to delegate to either the portable
or native ABIInfo, and remove checkCallingConvention which was now a no-op
override.
Reviewers: jvoung
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D7206
llvm-svn: 227362
The test was fixed after a discussion with the revision author: the check
pattern was made more flexible as the "%call" part is not what we actually want
to check strictly there.
The original patch description:
===
Introduce SPIR calling conventions.
This implements Section 3.7 from the SPIR 1.2 spec:
SPIR kernels should use "spir_kernel" calling convention.
Non-kernel functions use "spir_func" calling convention. All
other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
===
llvm-svn: 226561
This implements Section 3.7 from the SPIR 1.2 spec:
SPIR kernels should use "spir_kernel" calling convention.
Non-kernel functions use "spir_func" calling convention. All
other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
llvm-svn: 226548
Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.
llvm-svn: 225979
I'm not sure why we have OS.indent(Indent+2) for the system attribute,
but presumably we want the same behaviour for all attributes...
llvm-svn: 225802
even though every basic source character literal has the same numerical value
as a narrow or wide character literal.
It appears that the FreeBSD folks are trying to use this macro to mean
something other than what the relevant standards say it means, but their usage
is conforming, so put up with it.
llvm-svn: 225751
Clang would treat the digits in an "11m" input constraint separately as
if it was handling constraint 1 twice instead of constraint 11.
llvm-svn: 225606
Input constraints like "0" and "[foo]" should be treated the same when
it comes to their corresponding output constraint.
This fixes PR21850.
llvm-svn: 225605
Add additional constraint checking for target specific behaviour for inline
assembly constraints. We would previously silently let all arguments through
for these constraints. In cases where the constraints were violated, we could
end up failing to select instructions and triggering assertions or worse,
silently ignoring instructions.
llvm-svn: 225244
use clang -cc1 matching the front end and backend. Fix up a couple
of tests that were testing aapcs for arm-linux-gnu.
The test that removes the aapcs abi calling convention removes
them because the default triple matches what the backend uses
for the calling convention there and so it doesn't need to be
explicitly stated - see the code in TargetInfo.cpp.
llvm-svn: 224491
Add a comment and a test to ~DiagnosticEngine about the ordering
requirements on the teardown of DiagnosticConsumer. This could also be
accomplished by rearranging the fields of ~DiagnosticEngine, but I felt
that this was a better, more explicit solution.
This fixes PR21911, an issue that occurred after the unique_ptr
migration in r222193.
llvm-svn: 224454
Summary:
Because GCC doesn't use $1 for code generation, inline assembly code can use $1 without having to add it to the clobbers list.
LLVM, on the other hand, does not shy away from using $1, and this can cause conflicts with inline assembly which assumes GCC-like code generation.
A solution to this problem is to make Clang automatically clobber $1 for all MIPS inline assembly.
This is not the optimal solution, but it seems like a necessary compromise, for now.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6638
llvm-svn: 224428
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
This way, the step generating SVNVersion.inc gets rerun every time someone
changes GetSVN.cmake (which is the file that decides how the contents of
SVNVersion.inc look). This makes hacking on GetSVN.cmake a bit easier.
llvm-svn: 223861
basic microarchitecture names, and add support (with tests) for parsing
all of the masic microarchitecture names for CPUs documented to be
accepted by GCC with -march. I didn't go back through the 32-bit-only
old microarchitectures, but this at least brings the recent architecture
names up to speed. This is essentially the follow-up to the LLVM commit
r223769 which did similar cleanups for the LLVM CPUs.
One particular benefit is that you can now use -march=westmere in Clang
and get the LLVM westmere processor which is a different ISA variant (!)
and so quite significant.
Much like with r223769, I would appreciate the Intel folks carefully
thinking about the macros defined, names used, etc for the atom chips
and newest primary x86 chips. The current patterns seem quite strange to
me, especially here in Clang.
Note that I haven't replicated the per-microarchitecture macro defines
provided by GCC. I'm really opposed to source code using these rather
than using ISA feature macros.
llvm-svn: 223776
is for each machine. Fix up darwin tests that were testing for
aapcs on armv7-ios when the actual ABI is apcs.
Should be no user visible change without -cc1.
llvm-svn: 223429
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
llvm-svn: 223271
Summary:
In particular, remove the defaults and reorder fields so it matches the result of DataLayout::getStringDescription().
Change by David Neto.
Reviewers: dschuff, sdt
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6482
llvm-svn: 223140
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
To support it in the frontend, the following has been added:
- generic address space type attribute;
- documentation for the OpenCL address space attributes;
- parsing of __generic(generic) keyword;
- test code for the parser and diagnostics.
llvm-svn: 222831
Summary:
This resolves [[ http://llvm.org/bugs/show_bug.cgi?id=17391 | PR17391 ]].
GCC's sources were used as a guide (couldn't find much information in ARM documentation).
Reviewers: doug.gregor, asl
Reviewed By: asl
Subscribers: asl, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D6339
llvm-svn: 222741
In order to keep SVNVersion.inc from being regenerated on every build, we need
to specify as a dependency a file that only changes when the VC state updates.
I previously just had .svn/entries, but that's only used by Subversion 1.6.
1.7 uses .svn/wc.db instead; prefer that if it's present.
(Thanks, Nico!)
llvm-svn: 222407
Now that LLVM's helper script GetSVN.cmake actually works consistently,
there's no reason not to use it. We avoid having to regenerate SVNVersion.inc
every time by marking it as dependent on Git's reflog or SVN's entries file.
This should end most of the issues of the AST format changing and breaking
old module files: CMake-Clang should now detect that the version changed just
like Autoconf-Clang has.
Based on r190557. Depends on LLVM r222391.
llvm-svn: 222393
Summary:
Make DiagnosticsEngine::takeClient return std::unique_ptr<>. Updated
callers to store conditional ownership using a pair of pointer and unique_ptr
instead of a pointer + bool. Updated code that temporarily registers clients to
use the non-owning registration (+ removed extra calls to takeClient).
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6294
llvm-svn: 222193
Remove flag parsing details from the public header.
Use SanitizerSet to represent the set of enabled sanitizers.
Cleanup the implementation: update the comments to
reflect reality, remove dead code.
No functionality change.
llvm-svn: 221968
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
Get rid of ugly SanitizerOptions class thrust into LangOptions:
* Make SanitizeAddressFieldPadding a regular language option,
and rely on default behavior to initialize/reset it.
* Make SanitizerBlacklistFile a regular member LangOptions.
* Introduce the helper class "SanitizerSet" to represent the
set of enabled sanitizers and make it a member of LangOptions.
It is exactly the entity we want to cache and modify in CodeGenFunction,
for instance. We'd also be able to reuse SanitizerSet in
CodeGenOptions for storing the set of recoverable sanitizers,
and in the Driver to represent the set of sanitizers
turned on/off by the commandline flags.
No functionality change.
llvm-svn: 221653
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
This CPU definition is redundant. The Cortex-A9 is defined as
supporting multiprocessing extensions. Remove references to this CPU.
This CPU was recently removed from LLVM. See http://reviews.llvm.org/D6057
Change-Id: I62ae7cc656fcae54fbaefc4b6976e77e694a8678
llvm-svn: 221458
Eli Bendersky