Summary:
Historically, NetBSD, FreeBSD and OpenBSD have defined the macro ABICALLS in
the preprocessor when -mabicalls is in effect.
Mainline GCC later defined __mips_abicalls when -mabicalls is in effect.
This patch teaches the preprocessor to define these macros when appropriate.
NetBSD does not require the ABICALLS macro.
This resolves PR/31694.
Thanks to Sean Bruno for highlighting this issue!
Reviewers: slthakur, seanbruno
Reviewed By: seanbruno
Subscribers: joerg, brad, emaste, seanbruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D29032
llvm-svn: 295728
This is a followup change to add v7ve support to clang for gcc
compatibility. Please see r294661.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29773
llvm-svn: 294662
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
GCC 7 will predefine two new macros on s390x:
- __ARCH__ indicates the ISA architecture level
- __VX__ indicates that the vector facility is available
This adds those macros to clang as well to ensure continued
compatibility with GCC.
llvm-svn: 294197
GCC does not generate `__unix` nor `unix` macros. The latter already
intrudes into the user's namespace and should be avoided. Use the
canonical spelling of `__unix__` across all the targets.
llvm-svn: 294148
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
Summary:
CUDA lets users share structs between the host and device, so for that
and other reasons, primitive types such as ptrdiff_t should be the same
on both sides of the compilation.
Our code to do this wasn't entirely successful. In particular, we did a
bunch of work during the NVPTXTargetInfo constructor, only to override
it in the NVPTX{32,64}TargetInfo constructors. It worked well enough on
Linux and Mac, but Windows is LLP64, which is different enough to break
it.
This patch removes the NVPTX{32,64}TargetInfo classes entirely and fixes
the bug described above.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28322
llvm-svn: 291135
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
It should already be handled but a typo in the LANGSTANDARD() definition
was introduced in r147220.
Patch by Alexander Richardson, test case by me.
Differential Revision:https://reviews.llvm.org/D27427
llvm-svn: 288793
Summary:
This used to work because system headers are found in a (somewhat)
predictable set of locations on Linux. But this is not the case on
MacOS; without this change, we don't look in the right places for our
headers when doing device-side compilation on Mac.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26776
llvm-svn: 287286
Re-introduce r285411.
Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.
This change aims to add this option, pass it through to the preprocessor via
the options class, and when inclusions occur we output some information (+ test
cases).
Patch by Steve O'Brien!
Differential Revision: https://reviews.llvm.org/D26089
llvm-svn: 287275
Summary:
Just like gcc, we should have the -Og option as more and more software are using it:
https://llvm.org/bugs/show_bug.cgi?id=20765
Reviewers: echristo, dberlin, dblaikie, keith.walker.arm, rengolin
Subscribers: aprantl, friss, mehdi_amini, RKSimon, probinson, majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D24998
llvm-svn: 286602
Summary:
This macro should be defined only when the user directly specifies an
API level as part of an Android target. For any regular Android target,
we leave this macro undefined.
Bug: https://llvm.org/bugs/show_bug.cgi?id=30940
Reviewers: eugenis, pirama
Subscribers: tberghammer, cfe-commits, pirama, eugenis, danalbert
Differential Revision: https://reviews.llvm.org/D26491
llvm-svn: 286543
Summary: This is needed to make the v64i8 and v32i16 types legal for the 512-bit VBMI instructions. Fixes PR30912.
Reviewers: delena, zvi
Subscribers: RKSimon, cfe-commits
Differential Revision: https://reviews.llvm.org/D26306
llvm-svn: 286340
For compatibility with other compilers on the platform, allow specifying
levels of the z/Architecture instead of model names with -march. In
particular, the following aliases are now supported:
-march=arch8 equals -march=z10
-march=arch9 equals -march=z196
-march=arch10 equals -march=zEC12
-march=arch11 equals -march=z13
This parallels the equivalent (and prerequisite) LLVM change in r285577.
llvm-svn: 285578
Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.
This change aims to add this option, pass it through to the preprocessor via
the options class, and when inclusions occur we output some information (+ test
cases).
Patch by Steve O'Brien!
Differential Revision: https://reviews.llvm.org/D25153
llvm-svn: 285411
r276653 suppressed the pragma once warning when generating a PCH file.
This patch extends that to any main file for which clang is told (with
the -x option) that it's a header file. It will also suppress the
warning "#include_next in primary source file".
Differential Revision: http://reviews.llvm.org/D25989
llvm-svn: 285295
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.
llvm-svn: 282974
This patch corresponds to review:
https://reviews.llvm.org/D24397
It adds the __POWER9_VECTOR__ macro and the -mpower9-vector option along with
a number of altivec.h functions (refer to the code review for a list).
llvm-svn: 282481
Like NetBSD, OpenBSD prefers having a consistent set of typedefs
across the architectures it supports over strictly following the ARM
ABIs. The diff below makes sure that clang's view of those types
matches OpenBSD's system header files. It also adds a test that
checks the relevant types on all OpenBSD platforms that clang works
on. Hopefully we can add mips64 and powerpc to that list in the
future.
Patch by Mark Kettenis <mark.kettenis@xs4all.nl>
llvm-svn: 282184
Summary: People might want to receive warnings about pragmas but not about intrinsics that are implemented in intrin.h.
Reviewers: thakis, hans
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24775
llvm-svn: 282108
Summary:
This fixes a bug where we were unable to compile the following CUDA
file with libstdc++ (didn't try libc++):
#include <future>
void foo() { std::shared_future<int> x; }
The problem is that <future> only defines std::shared_future if
__GCC_ATOMIC_INT_LOCK_FREE > 1. When we compiled this file for device,
the macro was set to 1, and then the class didn't exist at all.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: https://reviews.llvm.org/D24407
llvm-svn: 281089
Parse pragma intrinsic, display warning if the function isn't a builtin
function in clang and suggest including intrin.h.
Patch by Albert Gutowski!
Reviewers: aaron.ballman, rnk
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D23944
llvm-svn: 280825
OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets.
The default for targets was also apparently big endian, so AMDGPU
was incorrectly reported as big endian. Set this from the triple
so targets don't have another place to set the endianness.
llvm-svn: 280787
I'm in the progress of adding ARMv6 support to CloudABI. On the compiler
side, everything seems to work properly with this tiny change applied.
llvm-svn: 280672
Summary:
We want wasm and asmjs to have matching ABIs, and right now asmjs uses
unsigned int for its size_t. This causes exported symbols in libcxx to
not match and can cause weird breakage where libcxx doesn't get linked
as a result. Long-term we probably want wasm32, wasm64, and asmjs to
all use unsigned long, but that would cause unnecessary ABI churn for
asmjs so defer that until we can make all the ABI changes at once.
Patch by Jacob Gravelle
Differential Revision: https://reviews.llvm.org/D24134
llvm-svn: 280420
Recently, Microsoft added support for a flag, /std, which controls which
version of the language rules MSVC should use.
MSVC hasn't updated __cplusplus though.
Instead, they added a new macro, _MSVC_LANG, which is defined in a
similar fashion to __cplusplus. This is used to indicate which mode the
compiler is in.
llvm-svn: 273987
The PIC and PIE levels are not independent. In fact, if PIE is defined
it is always the same as PIC.
This is clear in the driver where ParsePICArgs returns a PIC level and
a IsPIE boolean. Unfortunately that is currently lost and we pass two
redundant levels down the pipeline.
This patch keeps a bool and a PIC level all the way down to codegen.
llvm-svn: 273566
This reverts commit r270688 and r270689. The issue is not a random order, but a
different order for some targets and others (prob. Linux vs Darwin). Reverting until
we have a better fix.
llvm-svn: 270691
licensees actually see in the toolchain we deliver to them. This will
reduce the set of local patches we have to maintain. The triple is
not changing. (The term ORBIS is an internal code name for PS4.)
llvm-svn: 269671
Embedded ARM MachO targets are AAPCS but not full EABI (we don't use
__aeabi_whatever and the functions are allowed to be hard-float).
Turns out there was already a test for this, but its original purpose had
become corrupted over the years.
llvm-svn: 269487
This patch corresponds to review:
http://reviews.llvm.org/D19684
It simply adds the handling for the option and the corresponding macros.
llvm-svn: 268951
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
Replace use of /dev/null with /var/empty. lit will substitute the /dev/null
include path resulting in failures. Use a path under /var/empty which is
supposed to be empty to ensure that we can successfully test.
llvm-svn: 268784
From the GCC manpage:
-I dir
... If dir begins with =, then the = will be replaced by the sysroot prefix;
see --sysroot and -isysroot.
Add support to expand the `=` as a prefix of the include path with the sysroot
if specified. `-isysroot` takes precedence over `--sysroot` as the normal
argument behaviour occurs. The ordering of the `-isysroot` is relevant to the
path substituted. If no `--sysroot=` or `-isysroot` option is present, the = is
not expanded.
Resolves PR26965!
llvm-svn: 268777
Summary:
Host and device types must match, otherwise when we pass values back and
forth between the host and device, we will get the wrong result.
This patch makes NVPTXTargetInfo inherit most of its type information
from the host's target info.
Reviewers: rsmith
Subscribers: cfe-commits, jhen, tra
Differential Revision: http://reviews.llvm.org/D19346
llvm-svn: 268131
Summary: The Darwin armv7k ABI uses Dwarf EH, so we need to set the OS define correctly. Without this the gcc_personality fails to build.
Reviewers: t.p.northover
Subscribers: aemerson, cfe-commits, rengolin
Differential Revision: http://reviews.llvm.org/D19693
llvm-svn: 268078
Summary:
According to the ACLE spec, "__ARM_FEATURE_FMA is defined to 1 if
the hardware floating-point architecture supports fused floating-point
multiply-accumulate".
This changes clang's behaviour from emitting this macro for v7-A and v7-R
cores to only emitting it when the target has VFPv4 (and therefore support
for the floating point multiply-accumulate instruction).
Fixes PR27216
Reviewers: t.p.northover, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: http://reviews.llvm.org/D18963
llvm-svn: 267869
OpenCL spec requires __OPENCL_C_VERSION__ to be defined based on -cl-std option. This patch implements that.
The patch also defines __FAST_RELAXED_MATH__ based on -cl-fast-relaxed-math option.
Also fixed a test using -std=c99 for OpenCL program. Limit allowed language standard of OpenCL to be OpenCL standards.
Differential Revision: http://reviews.llvm.org/D19071
llvm-svn: 267590
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
Summary:
The parsing logic has been separated out from the macro implementation logic, leading to a number of improvements:
* Gracefully handle unexpected/invalid tokens, too few, too many and nested parameters
* Provide consistent behaviour between all built-in feature-like macros
* Simplify the implementation of macro logic
* Fix __is_identifier to correctly return '0' for non-identifiers
Reviewers: doug.gregor, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D17149
llvm-svn: 265381
btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE.
Differential Revision: http://reviews.llvm.org/D17682
llvm-svn: 262772
Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).
Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.
Differential Revision: http://reviews.llvm.org/D17183
llvm-svn: 262737
You can override the value of these during CMake, and we often use sentinels
with more than one digit (not to mention our actual Clang being 700.whatever).
llvm-svn: 260596
This required fixing a few check lines which had omitted trailing
characters, and were passing incorrectly (e.g., asserting that
__UINT64_C_SUFFIX__ is "UL" instead of the "ULL" that it actually is set
to). All were obviously broken tests, not broken code.
llvm-svn: 260542
This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the
triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a).
The FP16 extension can be enabled with the "+fp16" suffix to the -march
or -mcpu option. This is consistent with the AArch64 option, rather than
the usual ARM option of -mfpu. We have agreed with the team which will
be upstreaming this to GCC that we want to use this new option format
for new architecture extensions for both ARM and AArch64.
Most of the work for this was done by the TargetParser patch in llvm.
Differential Revision: http://reviews.llvm.org/D15040
llvm-svn: 260533
Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248] macros on SystemZ.
This fixes a miscompile of GCC C++11 standard library headers
due to use of those macros in an ABI-changing manner.
See e.g. /usr/include/c++/4.8.5/ext/concurrence.h:
// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
A different choice of __default_lock_policy causes different
sizes of several of the C++11 data structures, which are then
incompatible when inlined in clang-compiled code with what the
(GCC-compiled) external library expects.
This in turn leads to various crashes when using std::thread
in code compiled with clang, as see e.g. via the ThreadPool
unit tests. See PR 26473 for an example.
llvm-svn: 259931
If include files are used in the CUDA preprocessor tests it will cause a
failure due to a missing header file in hosts that do not match the triple
in the test. E.g. powerpc64le have CUDA support but the include files
cannot be used for an x86 target.
llvm-svn: 259769
The test tries to produce a large preprocessed output to the console, and checks
that we do not see any unexpected fatal errors.
The test is not enabled unless a lit parameter "--param enable_console=1" is
passed on the command line to lit.py.
llvm-svn: 258902
Summary:
This fixes PR25875. When the trailing comma in a macro argument list is
elided, we need to treat it similarly to the case where a variadic macro
misses one actual argument.
Reviewers: rnk, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15670
llvm-svn: 258530
[cpp.cond]p4:
Prior to evaluation, macro invocations in the list of preprocessing
tokens that will become the controlling constant expression are replaced
(except for those macro names modified by the 'defined' unary operator),
just as in normal text. If the token 'defined' is generated as a result
of this replacement process or use of the 'defined' unary operator does
not match one of the two specified forms prior to macro replacement, the
behavior is undefined.
This isn't an idle threat, consider this program:
#define FOO
#define BAR defined(FOO)
#if BAR
...
#else
...
#endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch. Emit a warning about this undefined behavior.
One problem is that this also applies to function-like macros. While the
example above can be written like
#if defined(FOO) && defined(BAR)
#defined HAVE_FOO 1
#else
#define HAVE_FOO 0
#endif
there is no easy way to rewrite a function-like macro like `#define FOO(x)
(defined __foo_##x && __foo_##x)`. Function-like macros like this are used in
practice, and compilers seem to not have differing behavior in that case. So
this a default-on warning only for object-like macros. For function-like
macros, it is an extension warning that only shows up with `-pedantic`.
(But it's undefined behavior in both cases.)
llvm-svn: 258128
first token of the expansion, don't forget to copy the "is at the start of a
line" token (which is always false, as newlines cannot appear within a macro
body); otherwise, stringizing the result can insert spurious whitespace.
llvm-svn: 257863
Add/Subtract.
The following instructions are added to AArch32 instruction set:
- VQRDMLAH: Vector Saturating Rounding Doubling Multiply Accumulate
Returning High Half
- VQRDMLSH: Vector Saturating Rounding Doubling Multiply Subtract
Returning High Half
The following instructions are added to AArch64 instruction set:
- SQRDMLAH: Signed Saturating Rounding Doubling Multiply Accumulate
Returning High Half
- SQRDMLSH: Signed Saturating Rounding Doubling Multiply Subtract
Returning High Half
This patch adds intrinsic and ACLE macro support for these instructions,
as well as corresponding tests.
Differential Revision: http://reviews.llvm.org/D14982
llvm-svn: 254250
is not defined for 32bit mode, but __sparcv9 is. Pass down the correct
-target-cpu flags to the backend, so that instruction restrictions are
applied correctly. Pass down the correct -A flag when not using IAS.
The latter is limited to NetBSD targets in this commit.
llvm-svn: 252545
This patch implements two things in front-end for MCU psABI support:
1) "long double type is the same as double."
2) "New predefined C/C++ pre-processor symbols: iamcu and iamcu__.
Differential Revision: http://reviews.llvm.org/D14205
llvm-svn: 251786
This patch should add support for almost all command-line options and
driver tinkering necessary to produce a correct "clang -cc1"
invocation for watchOS and tvOS.
llvm-svn: 251706
The logic for parsing FP capabilities to set __ARM_FP was mistakenly removing
the Half-Precision capability when handling fp-only-sp resulting in a value
of 0x4. Section 6.5.1 of ACLE states that for such FP architectures the value
should be 0x6
llvm-svn: 250888
Simplifying the convoluted CPU handling in ARMTargetInfo.
The default base CPU on ARM is ARM7TDMI, arch ARMv4T, and
ARMTargetInfo had a different one. This wasn't visible from
Clang because the driver selects the defaults and sets the
Arch/CPU features directly, but the constructor depended
on the CPU, which was never used.
This patch corrects the mistake and greatly simplifies
how CPU is dealt with (essentially by removing the duplicated
DefaultCPU field).
Tests updated.
llvm-svn: 249699
We support all __sync_val_compare_and_swap_* builtins (only 64-bit on 64-bit
targets) on all cores, and should define the corresponding
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros, just as GCC does. As it turns out,
this is really important because they're needed to prevent a bad ODR violation
with libstdc++'s std::shared_ptr (this is well explained in PR12730).
We were doing this only for P8, but this is necessary on all PPC systems.
llvm-svn: 249009
Currently it's 64-bit which will lead to mismatch between host and
device code if we compile for i386.
Differential Revision: http://reviews.llvm.org/D13181
llvm-svn: 248753
WebAssembly's spec has now been updated to specify some guarantees
about lock free atomic accesses. Update clang to match.
This also updates sig_atomic_t to be 64-bit on wasm64. WebAssembly
does not presently have asynchronous interrupts, but this change is
within the spirit of how they will work if they are added.
Differential Revision: http://reviews.llvm.org/D12862
llvm-svn: 247624
This makes int_fast64_t and int_least64_t the same type as int64_t, and
eliminates a difference between wasm32 and wasm64.
Differential Revision: http://reviews.llvm.org/D12861
llvm-svn: 247622
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
The ACLE (ARM C Language Extensions) 2.0 defines that the predefined macro
__ARM_FP16_ARGS should be defined if __fp16 can be used as an argument and
result.
The support for __fp16 to be used as an argument and result is already
implemented for AArch64 so this change is just adding the missing macro.
Differential Revision: http://reviews.llvm.org/D12240
llvm-svn: 245833
When displaying the macro backtrace, ignore some of the backtraces that do not
provide extra information to the diagnostic. Typically, if the problem is
entirely contained within a macro argument, the macro expansion is often not
needed. Also take into account SourceRange's attached to the diagnostic when
selecting which backtraces to ignore. Two previous test cases have also been
updated.
Patch by Zhengkai Wu, with minor formatting fixes.
Differential Revision: http://reviews.llvm.org/D11778
llvm-svn: 244788
Summary:
Currently, if the argument to _Pragma is not a parenthesised string
literal, the bad token will be consumed, as well as the ')', if present.
If additional bad tokens are passed to the _Pragma, this results in
extra error messages which may distract from the true problem.
The proposed patch causes all tokens to be consumed until the closing
')' or a new line, whichever is reached first.
Reviewers: hfinkel, rsmith
Subscribers: hubert.reinterpretcast, fraggamuffin, rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D8308
Patch by Rachel Craik!
llvm-svn: 243692
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
(Keep -Wmsvc-include around as an alias.)
While here, also replace the one other mention of "MSVC" in diagnostics with
"Microsoft", for consistency.
llvm-svn: 243444
We ended up with the wrong predefine after the recent TargetParser shuffle, and
I accidentally solidified it with a test. This should fix it.
llvm-svn: 242841
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mtune option for the AArch64 target.
Differential Revision: http://reviews.llvm.org/D10563
llvm-svn: 242663
MSVC 4.2 didn't have bool as a builtin type but MSVC 5.0 does. When
they added it, they added a macro (__BOOL_DEFINED) which allows build
scripts and the like to know if they should provide their own bool.
Clang always supports bool as a builtin type in C++ mode.
llvm-svn: 242307
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -march option for the AArch64 target.
llvm-svn: 240019
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option for the AArch64 target.
llvm-svn: 239619
The main effect of this is to fix anomalies where certain -mfpu options didn't
disable everything that they should causing strange behaviour when combined
with -mcpu or -march values that themselves enabled fpu subtarget features,
e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as
-mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled.
Invalid -mfpu options now also give an error, which is consistent with the
handling of the .fpu directive.
Differential Revision: http://reviews.llvm.org/D10239
llvm-svn: 239152
They should be 'int' instead of 'long int' everywhere else except
NetBSD too, from what I gather in GCC's spec files. So, optimistically
changing it for everyone else, too.
llvm-svn: 239046
Cygwin (and MinGW) targets define __declspec to __attribute__ unless
-fms-extensions is specified. It turns out that cygwin headers rely on
the existence of this macro.
llvm-svn: 238394
"1-4" specifiers are returned as numeric constants, not identifiers,
and should be treated as such. Currently pragma handler incorrectly
assumes that they are returned as identifiers.
Patch by Andrey Bokhanko.
Differential Revision: http://reviews.llvm.org/D9856
llvm-svn: 238129
Follow-up to commit for revision 236848.
Just a test case for the macro definition under the right CPU/Arch.
One combination was actually missed in the initial fix:
- powerpc64-unknown-unknown -mcpu=pwr8 (rather than -mcpu=power8).
llvm-svn: 237386
In public MS headers for XAudio, clang would fail to generate a valid UUID due to the UUID components being combined with the '-' UUID separators. Clang would attempting to recover but would preserve the leading whitespace from the tokens after each failed paste leading to spaces creeping into the UUID and causing an error in the __declspace(uuid()) parsing.
Reference: Microsoft DirectX SDK (June 2010)\Include\XAudio2.h(51)
Resolves http://llvm.org/pr23071
llvm-svn: 235186
This patch generates a warning for invalid combination of '-mnan' and
'-march' options, it properly sets NaN encoding for a given '-march',
and it passes a proper NaN encoding to the assembler.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D8170
llvm-svn: 234882
Adds ARM Cortex-R4 and R4F support and tests in Clang. Though Cortex-R4
support was present, the support for hwdiv in thumb-mode was not defined
or tested properly. This has also been added.
llvm-svn: 234488
The zEC12 provides the transactional-execution facility. This is exposed
to users via a set of builtin routines on other compilers. This patch
adds clang support to enable those builtins. In partciular, the patch:
- enables the transactional-execution feature by default on zEC12
- allows to override presence of that feature via the -mhtm/-mno-htm options
- adds a predefined macro __HTM__ if the feature is enabled
- adds support for the transactional-execution GCC builtins
- adds Sema checking to verify the __builtin_tabort abort code
- adds the s390intrin.h header file (for GCC compatibility)
- adds s390 sections to the htmintrin.h and htmxlintrin.h header files
Since this is first use of target-specific intrinsics on the platform,
the patch creates the include/clang/Basic/BuiltinsSystemZ.def file and
hooks it up in TargetBuiltins.h and lib/Basic/Targets.cpp.
An associated LLVM patch adds the required LLVM IR intrinsics.
For reference, the transactional-execution instructions are documented
in the z/Architecture Principles of Operation for the zEC12:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/DZ9ZR009.pdf
The associated builtins are documented in the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc/S_002f390-System-z-Built-in-Functions.html
The htmxlintrin.h intrinsics provided for compatibility with the IBM XL
compiler are documented in the "z/OS XL C/C++ Programming Guide".
llvm-svn: 233804
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
PS4 target recognizes the #pragma comment() syntax as in -fms-extensions, but
only handles the case of #pragma comment(lib). This patch adds a warning if any
other arguments are encountered.
This patch also refactors the code in ParsePragma.cpp a little bit to make it
more obvious that some codes are being shared between -fms-extensions and PS4.
llvm-svn: 233015
These calls are usually guarded by checks for isAnnotation() but it
looks like we missed a spot. This would cause the included test to
crash clang.
llvm-svn: 232616
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
Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
llvm-svn: 230587
Before C11 there was only the DECIMAL_DIG definition. As of C11, we now
have one definition per floating point type (e.g. DBL_DECIMAL_DIG).
Change the existing code to define the new versions. To remain backward
compatible, define __DECIMAL_DIG__ as __LDBL_DECIMAL_DIG__.
Also update the tests. It seems that some of the existing test vectors
were incorrect. Change all tests for __DECIMAL_DIG__ to expect
__LDBL_DECIMAL_DIG__. Add tests for *_DECIMAL_DIG for FreeBSD/amd64, as
I happen to have such a system laying around. I've validated that the
values are in sync with <float.h>.
llvm-svn: 230207
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
Partially revert r223927 because LLVM gained support for 128-bit integers
in r227089. Modify and keep the tests that verify the definition of the
macro __SIZEOF_INT128__ for MIPS64 BE & LE in the preprocessor.
llvm-svn: 228918
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
Brad Smith