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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236104 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235976 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235397 91177308-0d34-0410-b5e6-96231b3b80d8
Clang would treat the digits in an "11m" input constraint separately as
if it was handling constraint 1 twice instead of constraint 11.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225606 91177308-0d34-0410-b5e6-96231b3b80d8
Input constraints like "0" and "[foo]" should be treated the same when
it comes to their corresponding output constraint.
This fixes PR21850.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225605 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225244 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215834 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
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
This makes it clear that TargetInfo doesn't capture the LangOptions object,
rather uses it to apply adjustments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212386 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204978 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199250 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197362 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190684 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190296 91177308-0d34-0410-b5e6-96231b3b80d8
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth.
As first commit for PR16752 fix: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth virtual methods. By default current behaviour could be implemented here.
2. Fix handleModeAttr according to new methods in TargetInfo.
This approach is implemented in the patch attached to this post.
Fixes:
1st Commit (Current): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth
2nd Commit (Next): Fix SemaDeclAttr, handleModeAttr function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190044 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a new common code feature that allows platform code to
request minimum alignment of global symbols. The background for this is
that on SystemZ, the most efficient way to load addresses of global symbol
is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction
provides PC-relative addressing, but only to *even* addresses. For this
reason, existing compilers will guarantee that global symbols are always
aligned to at least 2. [ Since symbols would otherwise already use a
default alignment based on their type, this will usually only affect global
objects of character type or character arrays. ] GCC also allows creating
symbols without that extra alignment by using explicit "aligned" attributes
(which then need to be used on both definition and each use of the symbol).
To enable support for this with Clang, this patch adds a
TargetInfo::MinGlobalAlign variable that provides a global minimum for the
alignment of every global object (unless overridden via explicit alignment
attribute), and adds code to respect this setting. Within this patch, no
platform actually sets the value to anything but the default 1, resulting
in no change in behaviour on any existing target.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181210 91177308-0d34-0410-b5e6-96231b3b80d8
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174768 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
AVX). Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size. Thus, very large vectors will be over-aligned with no
benefit. Target owners should set this target max.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160209 91177308-0d34-0410-b5e6-96231b3b80d8
This is equal to alignof(std::max_align_t) on the platform and equal to the
alignment provided by malloc. (Platform owners please double-check your
platform's value.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146762 91177308-0d34-0410-b5e6-96231b3b80d8
Alexey Bataev