| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26286
llvm-svn: 286376
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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/D15120
http://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
|
|
|
|
|
|
|
|
| |
Patch by Douglas Yung!
Differential Revision: http://reviews.llvm.org/D19003
llvm-svn: 267772
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: predefines __ELF__ macro for arm-none-eabi
Reviewers: silviu.baranga, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: http://reviews.llvm.org/D19225
llvm-svn: 266625
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts r265359.
It breaks
- llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
- llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
Failing Tests (5):
Clang :: FixIt/fixit-errors.c
Clang :: Preprocessor/init.c
Clang :: Sema/attr-deprecated.c
Clang :: Sema/nullability.c
Clang :: SemaObjC/objcbridge-attribute-arc.m
llvm-svn: 265601
|
|
|
|
|
|
|
|
| |
Patch by Douglas Yung!
Differential Revision: http://reviews.llvm.org/D18708
llvm-svn: 265359
|
|
|
|
|
|
|
|
|
|
| |
Changes to clang to add Lanai backend. Adds a new target, ABI and toolchain.
General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html).
Differential Revision: http://reviews.llvm.org/D17002
llvm-svn: 264655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Adjust the user label prefix for cygwin x86_64.
Resolves PR26744.
llvm-svn: 262030
|
|
|
|
|
|
|
| |
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 is same as GCC behavior (tested with GCC 4.8.2).
Differential Revision: http://reviews.llvm.org/D16365
llvm-svn: 258850
|
|
|
|
| |
llvm-svn: 252646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 246573
|
|
|
|
| |
llvm-svn: 244961
|
|
|
|
| |
llvm-svn: 242523
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It was unsigned before, which is unlike any other target and also doesn't make
much sense.
llvm-svn: 233836
|
|
|
|
| |
llvm-svn: 233830
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Equally to NetBSD, Bitrig will be using .eh_frame unwinding on ARM.
Patch by Patrick Wildt.
llvm-svn: 230763
|
|
|
|
| |
llvm-svn: 230761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|