| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
eventually creating a StringRef. NFC
llvm-svn: 250902
|
|
|
|
| |
llvm-svn: 250881
|
|
|
|
| |
llvm-svn: 250880
|
|
|
|
|
|
| |
positive and casting to unsigned. Since we know the string starts with a digit it couldn't be negative anyway. NFCI
llvm-svn: 250879
|
|
|
|
| |
llvm-svn: 250878
|
|
|
|
| |
llvm-svn: 250876
|
|
|
|
|
|
|
|
|
|
| |
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replace empty bodies of default constructors and destructors with '= default'.
Reviewers: bkramer, klimek
Subscribers: klimek, alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D13890
llvm-svn: 250822
|
|
|
|
|
|
| |
pointer and length. NFC". Hopefully this time the bots will be happy.
llvm-svn: 250678
|
|
|
|
|
|
| |
pointer and length. NFC"
llvm-svn: 250677
|
|
|
|
|
|
| |
length. NFC
llvm-svn: 250676
|
|
|
|
|
|
| |
TargetInfo class.
llvm-svn: 249872
|
|
|
|
|
|
| |
change the set of features.
llvm-svn: 249871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
|
|
|
|
| |
llvm-svn: 246565
|
|
|
|
|
|
| |
This reverts commit r246468 while we figure out what to do about Basic and AST.
llvm-svn: 246508
|
|
|
|
|
|
|
|
|
| |
Also:
- Add a typedef to make working with the result easier.
- Update callers to use the new function.
- Make initFeatureMap out of line.
llvm-svn: 246468
|
|
|
|
|
|
| |
string name.
llvm-svn: 246021
|
|
|
|
|
|
| |
use of the string.
llvm-svn: 244178
|
|
|
|
|
|
|
|
|
|
| |
can be different from the normal variable maximum.
Add an error diagnostic for when TLS variables exceed maximum TLS alignment.
Currenty only PS4 sets an explicit maximum TLS alignment.
Patch by Charles Li!
llvm-svn: 242198
|
|
|
|
|
|
|
|
|
| |
default simd alignment.
Adds type trait "__builtin_omp_required_simd_align" after discussions here http://reviews.llvm.org/D9894
Differential Revision: http://reviews.llvm.org/D10597
llvm-svn: 241237
|
|
|
|
|
|
|
|
| |
This issue was fixed elsewhere in r235396 in a more general way, hence these
changes no longer do anything. Keep the testcase however, to ensure that we
don't regress this for ARM.
llvm-svn: 236104
|
|
|
|
|
|
|
|
|
| |
When creating a global variable with a type of a struct with bitfields, we must
forcibly set the alignment of the global from the RecordDecl. We must do this so
that the proper bitfield alignment makes its way down to LLVM, since clang will
mangle the bitfields into one large type.
llvm-svn: 235976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GCC construct __attribute__((aligned)) is defined to set alignment
to "the default alignment for the target architecture" according to
the GCC documentation:
The default alignment is sufficient for all scalar types, but may not be
enough for all vector types on a target that supports vector operations.
The default alignment is fixed for a particular target ABI.
clang currently hard-coded an alignment of 16 bytes for that construct,
which is correct on some platforms (including X86), but wrong on others
(including SystemZ). Since this value is ABI-relevant, it is important
to get correct for compatibility purposes.
This patch adds a new TargetInfo member "DefaultAlignForAttributeAligned"
that targets can set to the appropriate default __attribute__((aligned))
value.
Note that I'm deliberately *not* using the existing "SuitableAlign"
value, which is used to set the pre-defined macro __BIGGEST_ALIGNMENT__,
since those two values may not be the same on all platforms. In fact,
on X86, __attribute__((aligned)) always uses 16-byte alignment, while
__BIGGEST_ALIGNMENT__ may be larger if AVX-2 or AVX-512 are supported.
(This is actually not yet correctly implemented in clang either.)
The patch provides a value for DefaultAlignForAttributeAligned only for
SystemZ, and leaves the default for all other targets at 16, which means
no visible change in behavior on all other targets. (The value is still
wrong for some other targets, but I'd prefer to leave it to the target
maintainers for those platforms to fix.)
llvm-svn: 235397
|
|
|
|
| |
llvm-svn: 230253
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7148
llvm-svn: 229680
|
|
|
|
| |
llvm-svn: 225942
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 225603
|
|
|
|
| |
llvm-svn: 225600
|
|
|
|
|
|
| |
Don't permit '+&m' to make it to CodeGen, it's invalid.
llvm-svn: 225586
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Name might be empty again after we removed the '%' prefix
and Name[0] would assert.
Found on code like
register int foo asm("%" MACRO);
where MACRO was supposed to be defined in a header file that was not found.
llvm-svn: 215834
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 214119
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 213301
|
|
|
|
|
|
| |
underlaying types.
llvm-svn: 213063
|
|
|
|
| |
llvm-svn: 212987
|
|
|
|
|
|
|
| |
This makes it clear that TargetInfo doesn't capture the LangOptions object,
rather uses it to apply adjustments.
llvm-svn: 212386
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add predefined stdint macros that match the given patterns:
U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}
http://reviews.llvm.org/D4141
Author: binji
llvm-svn: 211657
|
|
|
|
| |
llvm-svn: 208280
|
|
|
|
|
|
|
|
|
| |
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
|
|
|
|
|
|
| |
floats.
llvm-svn: 197592
|
|
|
|
|
|
|
|
|
|
| |
An empty string for an ASM input constraint is invalid, and will crash
during clang CodeGen. Change TargetInfo::validateInputConstraint to
reject an empty string.
<rdar://problem/15552191>
llvm-svn: 197362
|
|
|
|
| |
llvm-svn: 197268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.
Patch by Michele Scandale!
llvm-svn: 190684
|
|
|
|
| |
llvm-svn: 190390
|
|
|
|
|
|
|
|
|
|
|
| |
other C-family
languages, as well as specifying errno is not set by the math functions. Make the
clang front-end set those appropriately when the OpenCL language option is set.
Patch by Erik Schnetter!
llvm-svn: 190296
|
|
|
|
|
|
| |
-- For TargetInfo::getRealTypeByWidth also added support for IEEEQuad float type.
llvm-svn: 190294
|