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.
llvm-svn: 213747
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
This tweaks the diagnostic wording slighly, and adds a fixit on a note.
An alternative would be to add the fixit directly on the diagnostic, see
the review thread linked to from the bug for a few notes on that approach.
llvm-svn: 213725
being declared, not at the end. When pretty-printing a non-type template
parameter, put the name of the parameter in the middle of the type, not at the
end.
llvm-svn: 213718
Windows ARM indicates __va_start as a variadic function. However, the function
itself is treated as having 4 formal arguments:
- (out) pointer to the va_list
- (in) address of the last named argument
- (in) slot size for the type of the last argument
- address of the last named argument
The last argument does not seem to have any bearing on codegen, and thus is not
explicitly type checked at this point.
Unlike the previous handling for __va_start, it does not currently validate if
the parameter is the last named parameter (it seems that MSVC currently accepts
this).
llvm-svn: 213595
If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.
This patch fixes PR20055.
Differential Revision: http://reviews.llvm.org/D4378
llvm-svn: 213594
Summary:
This pragma is very rare. We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.
If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it. Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors. We would have to teach LLVM to
lower prioritized global ctors on COFF as well.
This should let us compile some silly uses of this pragma in WebKit /
Blink.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4549
llvm-svn: 213593
Both /showIncludes and /E write to stdout. Allowing both results
in interleaved output and an error when double-closing the file
descriptor, intended to catch issues like this.
llvm-svn: 213589
This fixes a couple of asserts when analyzing comparisons involving
C11 atomics that were uncovered by r205608 when we extended the
applicability of -Wtautological-constant-out-of-range-compare.
llvm-svn: 213573
In addition to enabling ELFv2 homogeneous aggregate handling,
LLVM support to pass array types directly also enables a performance
enhancement. We can now pass (non-homogeneous) aggregates that fit
fully in registers as direct integer arrays, using an element type
to encode the alignment requirement (that would otherwise go to the
"byval align" field).
This is preferable since "byval" forces the back-end to write the
aggregate out to the stack, even if it could be passed fully in
registers. This is particularly annoying on ELFv2, if there is
no parameter save area available, since we then need to allocate
space on the callee's stack just to hold those aggregates.
Note that to implement this optimization, this patch does not attempt
to fully anticipate register allocation rules as (defined in the
ABI and) implemented in the back-end. Instead, the patch is simply
passing *any* aggregate passed by value using the array mechanism
if its size is up to 64 bytes. This means that some of those will
end up being passed in stack slots anyway, but the generated code
shouldn't be any worse either. (*Large* aggregates remain passed
using "byval" to enable optimized copying via memcpy etc.)
llvm-svn: 213495
This patch implements clang support for the PowerPC ELFv2 ABI.
Together with a series of companion patches in LLVM, this makes
clang/LLVM fully usable on powerpc64le-linux.
Most of the ELFv2 ABI changes are fully implemented on the LLVM side.
On the clang side, we only need to implement some changes in how
aggregate types are passed by value. Specifically, we need to:
- pass (and return) "homogeneous" floating-point or vector aggregates in
FPRs and VRs (this is similar to the ARM homogeneous aggregate ABI)
- return aggregates of up to 16 bytes in one or two GPRs
The second piece is trivial to implement in any case. To implement
the first piece, this patch makes use of infrastructure recently
enabled in the LLVM PowerPC back-end to support passing array types
directly, where the array element type encodes properties needed to
handle homogeneous aggregates correctly.
Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
GPRs/stack slots (for float / vector / integer element types,
respectively)
- what the alignment requirements of the parameter are when passed in
GPRs/stack slots (8 for float / 16 for vector / the element type
size for integer element types) -- this corresponds to the
"byval align" field
With this support in place, the clang part simply needs to *detect*
whether an aggregate type implements a float / vector homogeneous
aggregate as defined by the ELFv2 ABI, and if so, pass/return it
as array type using the appropriate float / vector element type.
llvm-svn: 213494
C99 array parameters can have index-type CVR qualifiers, and the TypePrinter
should print them when present (and we were not for constant-sized arrays).
Otherwise, we'd drop the restrict in:
int foo(int a[restrict static 3]) { ... }
llvm-svn: 213445
In C99, an array parameter declarator might have the form:
direct-declarator '[' 'static' type-qual-list[opt] assign-expr ']'
where the static keyword indicates that the caller will always provide a
pointer to the beginning of an array with at least the number of elements
specified by the assignment expression. For constant sizes, we can use the
new dereferenceable attribute to pass this information to the optimizer. For
VLAs, we don't know the size, but (for addrspace(0)) do know that the pointer
must be nonnull (and so we can use the nonnull attribute).
llvm-svn: 213444
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
llvm-svn: 213443
Thoroughly check for a pointer dereference which yields a glvalue. Look
through casts, comma operators, conditional operators, paren
expressions, etc.
This was originally D4416.
Differential Revision: http://reviews.llvm.org/D4592
llvm-svn: 213434
In C99, an array parameter declarator might have the form: direct-declarator
'[' 'static' type-qual-list[opt] assign-expr ']'
and when the size of the array is a constant, don't omit the static keyword
when printing the type. Also, in the VLA case, put a space after the static
keyword (some assignment expression must follow it).
llvm-svn: 213424
is unused (this is match behavior when property-dot syntax is used to
use same getter). rdar://17514245
Patch by Anders Carlsson with minor refactoring by me.
llvm-svn: 213423
thorough tests.
Original commit message:
[modules] Fix macro hiding bug exposed if:
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213416
This reverts commit r213401, r213402, r213403, and r213404.
I accidently committed these changes instead of updating the
differential.
llvm-svn: 213405
Summary:
Thoroughly check for a pointer dereference which yields a glvalue. Look
through casts, comma operators, conditional operators, paren
expressions, etc.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4416
llvm-svn: 213401
Tim Northover