This typically is only for a new enough linker (bfd >= 2.16.2 or gold), but
our ppc suppport post-dates this and it should work on all linux platforms. It
is guaranteed to work on all elfv2 platforms.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298765 91177308-0d34-0410-b5e6-96231b3b80d8
The le triple didn't exist until power8, so use that as a default (this
also matches what gcc does).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298759 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295728 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit SVN r294148. Seems that it was mistaken, and GCC
does still define `__unix` and `unix` when in GNU mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294332 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294148 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291082 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282974 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282184 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280787 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280672 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280420 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269671 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269487 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268898 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266460 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266186 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262737 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260596 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260542 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249699 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247624 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242307 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239046 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238394 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
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233544 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231912 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230207 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228918 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228367 91177308-0d34-0410-b5e6-96231b3b80d8
This is a temporary workaround while MIPS64 has not yet fully supported
128-bit integers. But declaration of int128 type is necessary even though
`__SIZEOF_INT128__` is undefined because c++ standard header files like
`limits` throw error message if `__int128` is not available.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D6402
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223927 91177308-0d34-0410-b5e6-96231b3b80d8
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220244 91177308-0d34-0410-b5e6-96231b3b80d8
The current default abi when no environment is given is "apcs-gnu",
which is obsolete. This patch changes the default to "aapcs". "aapcs" has both
hard- and soft-float variants, so the -mhard-float, -msoft-float and
-mfloat-abi= options now all behave as expected when no environment is
specified in the triple.
While writing this I also noticed that a preprocessor test claims to be
checking darwin, but is actually checking the defaults, which are
different for darwin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216662 91177308-0d34-0410-b5e6-96231b3b80d8
char-based types from "char" to "signed char". Adjust stdint.h to use
__INTx_TYPE__ directly without prefixing it with signed and to use
__UINTx_TYPE__ for unsigned ones.
The value of __INTx_TYPE__ now matches GCC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214119 91177308-0d34-0410-b5e6-96231b3b80d8
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214074 91177308-0d34-0410-b5e6-96231b3b80d8
arm64_be doesn't really exist; it was useful for testing while AArch64 and
ARM64 were separate, but now the only real way to refer to the system is
aarch64_be.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213747 91177308-0d34-0410-b5e6-96231b3b80d8
constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213301 91177308-0d34-0410-b5e6-96231b3b80d8
corresponding AST context function, only restricted to basic integer
types. Use this to ensure getUIntPtrType() gives types consistent with
getIntPtrType(). Fix NVPTX backend to give signed intptr_t.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212982 91177308-0d34-0410-b5e6-96231b3b80d8
This covers all tests in tests/Driver and tests/Preprocessor, but there are some
failing tests in test/Sema that need looking into.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206464 91177308-0d34-0410-b5e6-96231b3b80d8
Eric Christopher