| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The lit.cfg files only add .cpp to suffixes, so these tests used to never run,
oops. (Also tweak to of these tests in minor ways to make the actually pass.)
llvm-svn: 224718
|
| |
|
|
|
|
| |
(from patch r224549).
llvm-svn: 224713
|
| |
|
|
|
|
|
|
| |
when source range is incorrect causing the warning to be
issued when it should not because expression is in a macro.
rdar://19256338
llvm-svn: 224549
|
| |
|
|
|
|
| |
unevaluated expression context, such as sizeof(), or decltype(). Also adds a similar warning when the expression passed to typeid() *is* evaluated, since it is equally likely that the user would expect the expression operand to be unevaluated in that case.
llvm-svn: 224465
|
| |
|
|
|
|
| |
Patch by Anders Rönnholm
llvm-svn: 224268
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extension has the following syntax:
__builtin_call_with_static_chain(Call, Chain)
where Call must be a function call expression and Chain must be of pointer type
This extension performs a function call Call with a static chain pointer
Chain passed to the callee in a designated register. This is useful for
calling foreign language functions whose ABI uses static chain pointers
(e.g. to implement closures).
Differential Revision: http://reviews.llvm.org/D6332
llvm-svn: 224167
|
| |
|
|
|
|
|
| |
#undef a keyword is generally harmless but used often in configuration scripts.
Also added tests that I forgot to include to commit in r223114.
llvm-svn: 224100
|
| |
|
|
|
|
| |
since the attribute may reside there, instead of just on the FunctionDecl. Fixes PR21668.
llvm-svn: 224039
|
| |
|
|
|
|
| |
Recommit of r223114, reverted in r223120.
llvm-svn: 224012
|
| |
|
|
|
|
| |
_Generic expression are unevaluated.
llvm-svn: 223266
|
| |
|
|
|
|
| |
that contained side effects.
llvm-svn: 223184
|
| |
|
|
| |
llvm-svn: 223120
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Fixes PR21656, which is fallout from r222551 caused by an untested/missed
code path.
llvm-svn: 222694
|
| |
|
|
|
|
| |
Many thanks to dblaikie for his advices and suggestions!
llvm-svn: 222568
|
| |
|
|
|
|
| |
when calling DiagnoseEmptyLookup.
llvm-svn: 222551
|
| |
|
|
|
|
| |
for C code.
llvm-svn: 222327
|
| |
|
|
|
|
|
|
|
|
|
| |
nonnull attribute when comparison is always true/false.
Original patch by Steven Wu. I have added extra code to prevent issuing of
warning when the nonnull parameter is modified prior to the comparison.
This addition prevents false positives in the most obvious cases.
There may still be false positive warnings in some cases (as one of my tests
indicates), but benefit far outweighs such cases. rdar://18712242
llvm-svn: 222264
|
| |
|
|
|
|
|
| |
which evaluates to true. rdar://18716393.
Reviewed by Richard Trieu
llvm-svn: 222009
|
| |
|
|
| |
llvm-svn: 221945
|
| |
|
|
| |
llvm-svn: 221715
|
| |
|
|
|
|
| |
comments.
llvm-svn: 221714
|
| |
|
|
|
|
|
| |
That this is a c-only patch. c++ already has this warning.
This addresses rdar://18716393
llvm-svn: 221702
|
| |
|
|
|
|
|
|
|
|
|
| |
Now we don't warn on this code:
void __stdcall f(void);
void __stdcall f();
My previous commit regressed this functionality because I didn't update
the relevant test case which used a definition.
llvm-svn: 221188
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We already have a warning on the call sites of code like this:
void f() { }
void g() { f(1, 2, 3); }
t.c:2:21: warning: too many arguments in call to 'f'
We can limit ourselves to diagnosing unprototyped forward declarations
of f to cut down on noise.
llvm-svn: 221184
|
| |
|
|
|
|
|
|
| |
parameters with nonnull attribute when comparison is always
true/false. Patch causes false positive when parameter is
modified in the function.
llvm-svn: 221163
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 220763
|
| |
|
|
| |
llvm-svn: 220678
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
nonnull attribute when comparison is always
true/false. Patch by Steven Wu with few fixes and minor
refactoring and adding tests by me. rdar://18712242
llvm-svn: 220496
|
| |
|
|
|
|
|
|
| |
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
|
| |
|
|
|
|
| |
The test is a C++ semantic analysis test, move it to SemaCXX from Sema. NFC.
llvm-svn: 219932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing a type deduction from the return type, the FunctionDecl may be
attributed with a calling convention. In such a case, the retrieved type
location may be an AttributedTypeLoc. Performing a castAs<FunctionProtoTypeLoc>
on such a type loc would result in an assertion as they are not derived types.
Ensure that we correctly handle the attributed type location by looking through
it to the modified type loc.
Fixes an assertion triggered in C++14 mode.
llvm-svn: 219851
|
| |
|
|
|
|
| |
struct/union fields. This fixes PR20930.
llvm-svn: 219807
|
| |
|
|
|
|
|
| |
implicit casts. Reviewed by Reid Kleckner.
rdar://18405357
llvm-svn: 219712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes PR21155.
Test Plan: The patch includes a test.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5619
llvm-svn: 219322
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
naked functions (PR21178)
Clang won't emit any prologues for such functions, so it would assert trying to
codegen the parameter references.
This patch makes Clang check the extended asm inputs and outputs for
references to function parameters.
Differential Revision: http://reviews.llvm.org/D5640
llvm-svn: 219272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows TLS relies on indexing through a tls_index in order to get at
the DLL's thread local variables. However, this index is not exported
along with the variable: it is assumed that all accesses to thread local
variables are inside the same module which created the variable in the
first place.
While there are several implementation techniques we could adopt to fix
this (notably, the Itanium ABI gets this for free), it is not worth the
heroics.
Instead, let's just ban this combination. We could revisit this in the
future if we need to.
This fixes PR21111.
llvm-svn: 219049
|
| |
|
|
|
|
|
|
| |
This test includes stdint.h, which might include system headers (and that might
not work, depending on the system configuration). Attempting to fix
llvm-clang-lld-x86_64-debian-fast.
llvm-svn: 218959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a Clang-specific implementation of C11's stdatomic.h header. On systems,
such as FreeBSD, where a stdatomic.h header is already provided, we defer to
that header instead (using our __has_include_next technology). Otherwise, we
provide an implementation in terms of our __c11_atomic_* intrinsics (that were
created for this purpose).
C11 7.1.4p1 requires function declarations for atomic_thread_fence,
atomic_signal_fence, atomic_flag_test_and_set,
atomic_flag_test_and_set_explicit, and atomic_flag_clear, and requires that
they have external linkage. Accordingly, we provide these declarations, but if
a user elides the shadowing macros and uses them, then they must have a libc
(or similar) that actually provides definitions.
atomic_flag is implemented using _Bool as the underlying type. This is
consistent with the implementation provided by FreeBSD and also GCC 4.9 (at
least when __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1).
Patch by Richard Smith (rebased and slightly edited by me -- Richard said I
should drive at this point).
llvm-svn: 218957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to GCC 4.4, __sync_fetch_and_nand was implemented as:
{ tmp = *ptr; *ptr = ~tmp & value; return tmp; }
but this was changed in GCC 4.4 to be:
{ tmp = *ptr; *ptr = ~(tmp & value); return tmp; }
in response to this change, support for sync_fetch_and_nand (and
sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code
depending on the old semantics. However, at this point:
1. Many years have passed, and the amount of code relying on the old
semantics is likely smaller.
2. Through the work of many contributors, all LLVM backends have been updated
such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process
was complete July of 2014 (added to the release notes in r212635).
3. The lack of this intrinsic is now a needless impediment to porting codes
from GCC to Clang (I've now seen several examples of this).
It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC
4.2). To compensate for this, and to address the original concern regarding
code relying on the old semantics, I've added a warning that specifically
details the fact that the semantics have changed and that we provide the newer
semantics.
Fixes PR8842.
llvm-svn: 218905
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
we were failing to find that bit-field when performing integer promotions. This
brings us closer to following the standard, and closer to GCC.
In C, this change is technically a regression: we get bit-field promotions
completely wrong in C, promoting cases that are categorically not bit-field
designators. This change makes us do so slightly more consistently, though.
llvm-svn: 218428
|
| |
|
|
|
|
|
| |
This reverts bits of r218166 that are no longer necessary now that r218394 made
-Wmissing-prototype-for-cc a regular warning.
llvm-svn: 218400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR21027. The MIDL compiler produces code that does this.
If we wanted to improve the warning, I think we could do this:
void __stdcall f(); // Don't warn without -Wstrict-prototypes.
void g() {
f(); // Might warn, the user probably meant for f to take no args.
f(1, 2, 3); // Warn, we have no idea what args f takes.
f(1); // Error, this is insane, one of these calls is broken.
}
Reviewers: thakis
Differential Revision: http://reviews.llvm.org/D5481
llvm-svn: 218394
|
| |
|
|
|
|
|
| |
memccpy_check should have source and dest size at arg 3 and 4
rdar://18431336
llvm-svn: 218367
|
| |
|
|
|
|
| |
The type of size_t varies between targets.
llvm-svn: 218288
|