| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Mostly short-circuits some conditionals. Adds target validation of
sections passed to these pragmas.
llvm-svn: 231317
|
|
|
|
|
|
|
|
|
|
| |
MSVC doesn't warn on this. Users are expected to apply the WINAPI macro
to functions passed by pointer to the Win32 API, and this macro expands
to __stdcall. This means we end up with a lot of useless noisy warnings
about ignored calling conventions when compiling code with clang for
Win64.
llvm-svn: 230668
|
|
|
|
|
|
|
| |
results. No-one was ever modifying a lookup result, and it would not be
reasonable to do so.
llvm-svn: 230123
|
|
|
|
|
|
|
| |
can take a "const char*" format but supports standard printf
and CF/NS types . rdar://19904147
llvm-svn: 230109
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new __freebsd_kprintf__ format string type, which enables
checking when used in __attribute__((format(...))) attributes. It can
check the FreeBSD kernel specific %b, %D, %r and %y specifiers, using
existing diagnostic messages. Also adds test cases for all these
specifiers.
Differential Revision: http://reviews.llvm.org/D7154
llvm-svn: 229921
|
|
|
|
|
|
|
| |
Un-parameterize the warning as there is exactly one attribute added in C++14.
Partially addresses post-commit review comments from Richard Smith.
llvm-svn: 229636
|
|
|
|
|
|
| |
diagnosed.
llvm-svn: 229454
|
|
|
|
|
|
|
|
|
| |
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
llvm-svn: 229447
|
|
|
|
|
|
|
|
|
|
| |
__declspec(restrict) and __attribute(malloc) are both handled
identically by clang: they are allowed to the noalias LLVM attribute.
Seeing as how noalias models the C99 notion of 'restrict', rename the
internal clang attribute to Restrict from Malloc.
llvm-svn: 228120
|
|
|
|
|
|
|
| |
Clang is otherwise consistent that Microsoft be abbreviated as MS, not
Ms.
llvm-svn: 227842
|
|
|
|
|
|
|
|
|
|
| |
It is common for COM interface classes to be marked as 'novtable' to
tell the compiler that constructors and destructors should not reference
virtual function tables.
This commit implements this feature in clang.
llvm-svn: 227796
|
|
|
|
|
|
| |
rdar://19678874
llvm-svn: 227774
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It was used for interoperability with PNaCl's calling conventions, but
it's no longer needed.
Also Remove NaCl*ABIInfo which just existed to delegate to either the portable
or native ABIInfo, and remove checkCallingConvention which was now a no-op
override.
Reviewers: jvoung
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D7206
llvm-svn: 227362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We didn't consider any alignment attributes on an EnumDecl when
calculating alignment.
While we are here, ignore alignment specifications on typedef types if
one is used as the underlying type. Otherwise, weird things happen:
enum Y : int;
Y y;
typedef int __attribute__((aligned(64))) u;
enum Y : u {};
What is the alignment of 'Y'? It would be more consistent with the
overall design of enums with fixed underlying types to consider the
underlying type's UnqualifiedDesugaredType.
This fixes PR22279.
llvm-svn: 226653
|
|
|
|
|
|
|
| |
In a few places we didn't check that Category->getClassInterface() was
not null before using it.
llvm-svn: 226605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Things that are OK:
extern int var1 __attribute((alias("v1")));
static int var2 __attribute((alias("v2")));
Things that are not OK:
int var3 __attribute((alias("v3")));
extern int var4 __attribute((alias("v4"))) = 4;
We choose to accpet:
struct S { static int var5 __attribute((alias("v5"))); };
This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
no reason to reject it.
This partially fixes PR22217.
llvm-svn: 226436
|
|
|
|
|
|
|
|
|
|
|
|
| |
conflicting attribute, warn about the conflict and pick a "winning"
attribute to preserve, instead of emitting an error. This matches the
behavior when the conflicting attributes are on different declarations.
Along the way I discovered that conflicts involving __forceinline were
reported as 'always_inline' (alternate spelling, same attribute) so
fixed that up to report the attribute as spelled in the source.
llvm-svn: 225813
|
|
|
|
| |
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
|