| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
It shouldn't have been removed, the code which replaced it didn't cover
this case.
llvm-svn: 226442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
buitins.
llvm-svn: 226422
|
|
|
|
|
|
| |
reject CV void return type on C definitions per 6.9.1/3
llvm-svn: 226178
|
|
|
|
| |
llvm-svn: 225942
|
|
|
|
|
|
|
|
|
|
| |
We would check the type information from the declaration found by lookup
but we would neglect checking compatibility with the most recent
declaration. This would make it possible for us to not correctly
diagnose inconsistencies with declarations which were made in a
different scope.
llvm-svn: 225934
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
This is a different approach to r225780.
llvm-svn: 225875
|
|
|
|
|
|
|
| |
This reverts commit r225780, we can't compile line 181 in
sanitizer_platform_limits_posix.cc with this commit.
llvm-svn: 225781
|
|
|
|
|
|
|
|
|
|
| |
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
llvm-svn: 225780
|
|
|
|
|
|
|
| |
Clang would treat the digits in an "11m" input constraint separately as
if it was handling constraint 1 twice instead of constraint 11.
llvm-svn: 225606
|
|
|
|
|
|
|
|
|
| |
Input constraints like "0" and "[foo]" should be treated the same when
it comes to their corresponding output constraint.
This fixes PR21850.
llvm-svn: 225605
|
|
|
|
| |
llvm-svn: 225603
|
|
|
|
| |
llvm-svn: 225600
|
|
|
|
|
|
| |
Don't permit '+&m' to make it to CodeGen, it's invalid.
llvm-svn: 225586
|
|
|
|
|
|
| |
(I should have re-run the test after running clang-format)
llvm-svn: 225515
|
|
|
|
| |
llvm-svn: 225513
|
|
|
|
|
|
|
|
|
|
|
|
| |
transform.
Also diagnose typos in the initializer of an invalid C++ declaration.
Both issues were hit using the same line of test code, depending on
whether the code was treated as C or C++.
Fixes PR22092.
llvm-svn: 225389
|
|
|
|
|
|
| |
For now there is no difference between amdgcn and r600.
llvm-svn: 225294
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 225244
|
|
|
|
|
|
|
|
|
|
| |
Many places in Sema cannot handle isNull() types. This is fine, because in
most places the type building code recovers by falling back to IntTy. In
GetFullTypeForDeclarator(), this is done at the end of the getNumTypeObjects()
loop body. This function calls BuildQualifiedType() before this fallback is
done though, so it explicitly needs to check for isNull() types.
llvm-svn: 225124
|
|
|
|
|
|
| |
Verify that asm constraints have the same number of alternatives
llvm-svn: 224911
|
|
|
|
| |
llvm-svn: 224880
|
|
|
|
|
|
|
| |
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
|