| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 225414
|
|
|
|
|
|
|
|
| |
or an identifier. VariadicEnumArguments now behave consistently instead of only accepting a string literal.
This change affects the only attribute accepting a variadic enumeration: callable_when.
llvm-svn: 224582
|
|
|
|
|
|
| |
different declaration of the same function.
llvm-svn: 224256
|
|
|
|
|
|
|
|
|
|
| |
Sema::handleAnnotateAttr expects that some basic validation is done on
the given AttributeList. However, ProcessAccessDeclAttributeList called
it directly. Instead, pass the list to ProcessDeclAttribute.
This fixes PR21847.
llvm-svn: 224204
|
|
|
|
|
|
|
| |
Eventually we'll diagnose them on different declarations, but let's
get this part out of the way first.
llvm-svn: 223985
|
|
|
|
| |
llvm-svn: 223984
|
|
|
|
|
|
| |
Review feedback from recent changes to GetSVN.cmake.
llvm-svn: 223980
|
|
|
|
|
|
|
|
|
|
|
| |
Placing the attribute after the kernel keyword would incorrectly
reject the attribute, so use the smae workaround that other
kernel only attributes use.
Also add a FIXME because there are two different phrasings now
for the same error, althoug amdgpu_num_[sv]gpr uses a consistent one.
llvm-svn: 223490
|
|
|
|
|
|
| |
Only one of these can really match.
llvm-svn: 223489
|
|
|
|
| |
llvm-svn: 223403
|
|
|
|
|
|
|
| |
This is a performance hint that can be applied to kernels
to attempt to limit the number of used registers.
llvm-svn: 223384
|
|
|
|
|
|
|
|
|
|
|
| |
This attribute serves as a hint to improve warnings about the ranges of
enumerators used as flag types. It currently has no working C++ implementation
due to different semantics for enums in C++. For more explanation, see the docs
and testcases.
Reviewed by Aaron Ballman.
llvm-svn: 222906
|
|
|
|
|
|
| |
applies to situations where the namespace is mentioned. Thus, use on anonymous namespaces is diagnosed.
llvm-svn: 222054
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
llvm-svn: 221154
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
|
|
|
|
|
|
| |
Did a bit of drive-by reformatting as well since it required rearranging some other static functions in the file.
llvm-svn: 219795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the align_value attribute. This attribute is supported by
Intel's compiler (versions 14.0+), and several of my HPC users have requested
support in Clang. It specifies an alignment assumption on the values to which a
pointer points, and is used by numerical libraries to encourage efficient
generation of vector code.
Of course, we already have an aligned attribute that can specify enhanced
alignment for a type, so why is this additional attribute important? The
problem is that if you want to specify that an input array of T is, say,
64-byte aligned, you could try this:
typedef double aligned_double attribute((aligned(64)));
void foo(aligned_double *P) {
double x = P[0]; // This is fine.
double y = P[1]; // What alignment did those doubles have again?
}
the access here to P[1] causes problems. P was specified as a pointer to type
aligned_double, and any object of type aligned_double must be 64-byte aligned.
But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes
undefined behavior. Getting round this problem requires a lot of awkward
casting and hand-unrolling of loops, all of which is bad.
With the align_value attribute, we can accomplish what we'd like in a well
defined way:
typedef double *aligned_double_ptr attribute((align_value(64)));
void foo(aligned_double_ptr P) {
double x = P[0]; // This is fine.
double y = P[1]; // This is fine too.
}
This attribute does not create a new type (and so it not part of the type
system), and so will only "propagate" through templates, auto, etc. by
optimizer deduction after inlining. This seems consistent with Intel's
implementation (thanks to Alexey for confirming the various Intel-compiler
behaviors).
As a final note, I would have chosen to call this aligned_value, not
align_value, for better naming consistency with the aligned attribute, but I
think it would be more useful to users to adopt Intel's name.
llvm-svn: 218910
|
|
|
|
|
|
|
|
|
| |
In addition to __builtin_assume_aligned, GCC also supports an assume_aligned
attribute which specifies the alignment (and optional offset) of a function's
return value. Here we implement support for the assume_aligned attribute by making
use of the @llvm.assume intrinsic.
llvm-svn: 218500
|
|
|
|
|
|
|
|
|
|
|
| |
This makes use of the recently-added @llvm.assume intrinsic to implement a
__builtin_assume(bool) intrinsic (to provide additional information to the
optimizer). This hooks up __assume in MS-compatibility mode to mirror
__builtin_assume (the semantics have been intentionally kept compatible), and
implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM
now contains special logic to deal with assumptions of this form.
llvm-svn: 217349
|
|
|
|
| |
llvm-svn: 216976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the no-arguments case. Don't expand this to an __attribute__((nonnull(A, B,
C))) attribute, since that does the wrong thing for function templates and
varargs functions.
In passing, fix a grammar error in the diagnostic, a crash if
__attribute__((nonnull(N))) is applied to a varargs function,
a bug where the same null argument could be diagnosed multiple
times if there were multiple nonnull attributes referring to it,
and a bug where nonnull attributes would not be accumulated correctly
across redeclarations.
llvm-svn: 216520
|
|
|
|
|
|
| |
to an invalid function parameter type.
llvm-svn: 214723
|
|
|
|
|
|
| |
refers to an invalid function parameter type.
llvm-svn: 214722
|
|
|
|
| |
llvm-svn: 214526
|
|
|
|
|
|
| |
highlights the attribute and the faulty nonpointer type when possible.
llvm-svn: 214507
|
|
|
|
|
|
| |
attributes on the same declaration. This removes a FIXME from the code.
llvm-svn: 214436
|
|
|
|
| |
llvm-svn: 214411
|
|
|
|
|
|
|
|
| |
or optional arguments present. With this, the only time you should have to manually check attribute argument counts is when HasCustomParsing is set to true, or when you have variadic arguments that aren't really variadic (like ownership_holds and friends).
Updating the diagnostics in the launch_bounds test since they have been improved in that case. Adding a test for nonnull since it has little test coverage, but has truly variadic arguments.
llvm-svn: 214407
|
|
|
|
|
|
| |
feedback from Richard Smith. Amends r213657.
llvm-svn: 213865
|
|
|
|
|
|
| |
integer constants larger than 32-bits.
llvm-svn: 213658
|
|
|
|
|
|
| |
for my last patch. // rdar://17631257
llvm-svn: 213185
|
|
|
|
|
|
|
|
|
| |
to be applied to class or protocols. This will direct IRGen
for Objective-C metadata to use the new name in various places
where class and protocol names are needed.
rdar:// 17631257
llvm-svn: 213167
|
|
|
|
|
|
| |
Also consolidate 'backward compatibility'
llvm-svn: 212974
|
|
|
|
|
|
| |
it affects only the return value, not any arguments. In turn, asking for a function or method result type should not require a function prototype either, so getFunctionOrMethodResultType has been relaxed.
llvm-svn: 212827
|
|
|
|
| |
llvm-svn: 212442
|
|
|
|
|
|
|
| |
Also document that the function is a "best-effort" facility to extract source
ranges from limited AST type location info.
llvm-svn: 212174
|
|
|
|
| |
llvm-svn: 211648
|
|
|
|
| |
llvm-svn: 211647
|
|
|
|
|
|
|
| |
property accessor methods which have become deprecated
or available. // rdar://15951801
llvm-svn: 211039
|
|
|
|
|
|
| |
patch. NFC.
llvm-svn: 210795
|
|
|
|
|
|
|
| |
for function/methods returning block in MRR mode as well.
// rdar://17259812
llvm-svn: 210706
|
|
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
|
|
|
| |
llvm-svn: 209613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's true the MSVC doesn't warn about dllimport when applied to e.g. a typedef,
but that applies to dllexport too. I'd like us to be consistent, and I think
the right thing to do is to warn.
The original test that came with implementing the old behaviour doesn't provide
a good motivation, and it said it was checking that we're not repoting an *error*,
which is still true since this is just a warning.
There are plenty of tests e.g. in Sema/dllimport.c to check that we do warn
about dllimport on non functions or variables.
Differential Revision: http://reviews.llvm.org/D3832
llvm-svn: 209546
|
|
|
|
|
|
|
|
|
|
| |
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
llvm-svn: 209217
|
|
|
|
|
|
|
|
|
| |
This is a GNU attribute that allows split stacks to be turned off on a
per-function basis.
Differential Revision: http://reviews.llvm.org/D3817
llvm-svn: 209167
|
|
|
|
|
|
| |
Patch by Pedro Ferreira!
llvm-svn: 209127
|
|
|
|
|
|
|
|
| |
This is a step towards handling these attributes on classes (PR11170).
Differential Revision: http://reviews.llvm.org/D3772
llvm-svn: 208925
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
|
|
|
|
| |
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3551
llvm-svn: 207734
|