Given the following code:
int *_Nullable ptr;
int *_Nonnull nn = ptr;
...In C, clang will warn you about `nn = ptr`, because you're assigning
a nonnull pointer to a nullable pointer. In C++, clang issues no such
warning. This patch helps ensure that clang doesn't ever miss an
opportunity to complain about C++ code.
N.B. Though this patch has a differential revision link, the actual
review took place over email.
Differential Revision: http://reviews.llvm.org/D14938
llvm-svn: 255556
Currently, we emit warnings in some cases where nonnull function
parameters are compared against null. This patch extends this support
to warn when comparing the result of `returns_nonnull` functions
against null.
More specifically, we will now warn cases like:
int *foo() __attribute__((returns_nonnull));
int main() {
if (foo() == NULL) {} // warning: will always evaluate to false
}
Differential Revision: http://reviews.llvm.org/D15324
llvm-svn: 255058
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.
llvm-svn: 254992
The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests for the cases that were fixed.
llvm-svn: 254646
These additions were meant to go in as a part of r254554; while it's
certainly nice to have new functionality, it's nicer if we have tests to
go with it. :)
llvm-svn: 254632
This reverts commit r254143 which introduces a crash on the following input:
f(char *);
g(char *);
#pragma weak f = g
int g(char *p) {}
llvm-svn: 254605
This CL is for discussion how to better fix bit-filed layout compatibility issue with GCC (see PR25575 for test case and more details). Current clang behavior is compatible with GCC 4.1-4.3 series but it was fixed in 4.4+. Ignoring packed attribute looks very odd and because it was also fixed in GCC 4.4+, it makes sense also fix it in clang.
Differential Revision: http://reviews.llvm.org/D14872
llvm-svn: 254596
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.
This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.
This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:
float f = 1e100;
are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.
llvm-svn: 254574
Summary: This patch adds support for the interrupt attribute for mips32r2+.
Patch by Simon Dardis.
Reviewers: dsanders, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D10802
llvm-svn: 254205
Summary: This patch adds support for the interrupt attribute for mips32r2+.
Reviewers: dsanders, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D10802
llvm-svn: 254203
For MCU only C calling convention is allowed, all other calling conventions are not supported.
Differential Revision: http://reviews.llvm.org/D14864
llvm-svn: 254063
Summary: 's' is used to specify sgprs and 'v' is used to specify vgprs.
Reviewers: arsenm, echristo
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14307
llvm-svn: 253610
Add support for vector mode attributes like "attribute((mode(V4SF)))". Also add warning about deprecated vector modes like GCC does.
Differential Revision: http://reviews.llvm.org/D14744
llvm-svn: 253551
Currently, when there is a global register variable in a program that
is bound to an invalid register, clang/llvm prints an error message that
is not very user-friendly.
This commit improves the diagnostic and moves the check that used to be
in the backend to Sema. In addition, it makes changes to error out if
the size of the register doesn't match the declared variable size.
e.g., volatile register int B asm ("rbp");
rdar://problem/23084219
Differential Revision: http://reviews.llvm.org/D13834
llvm-svn: 253405
Clang tries to figure out if a call to abs is suspicious by looking
through implicit casts to look at the underlying, implicitly converted
type.
Interestingly, C has implicit conversions from pointer-ish types like
function to less exciting types like int. This trips up our 'abs'
checker because it doesn't know which variant of 'abs' is appropriate.
Instead, diagnose 'abs' called on function types upfront. This sort of
thing is highly suspicious and is likely indicative of a missing
pointer dereference/function call/array index operation.
This fixes PR25532.
llvm-svn: 253156
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
llvm-svn: 252986
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
This attribute is used to prevent tail-call optimizations to the marked
function. For example, in the following piece of code, foo1 will not be
tail-call optimized:
int __attribute__((not_tail_called)) foo1(int);
int foo2(int a) {
return foo1(a); // Tail-call optimization is not performed.
}
The attribute has effect only on statically bound calls. It has no
effect on indirect calls. Also, virtual functions and objective-c
methods cannot be marked as 'not_tail_called'.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12922
llvm-svn: 252369
GCC has a warning called -Wdouble-promotion, which warns you when
an implicit conversion increases the width of a floating point type.
This is useful when writing code for architectures that can perform
hardware FP ops on floats, but must fall back to software emulation for
larger types (i.e. double, long double).
This fixes PR15109 <https://llvm.org/bugs/show_bug.cgi?id=15109>.
Thanks to Carl Norum for the patch!
llvm-svn: 251588
1. Make the warning more strict in C mode. r172696 added code to suppress
warnings from macro expansions in system headers, which checks
`SourceMgr.isMacroBodyExpansion(E->IgnoreParens()->getExprLoc())`. Consider
this snippet:
#define FOO(x) (x)
void f(int a) {
FOO(a);
}
In C, the line `FOO(a)` is an `ImplicitCastExpr(ParenExpr(DeclRefExpr))`,
while it's just a `ParenExpr(DeclRefExpr)` in C++. So in C++,
`E->IgnoreParens()` returns the `DeclRefExpr` and the check tests the
SourceLoc of `a`. In C, the `ImplicitCastExpr` has the effect of checking the
SourceLoc of `FOO`, which is a macro body expansion, which causes the
diagnostic to be skipped. It looks unintentional that clang does different
things for C and C++ here, so use `IgnoreParenImpCasts` instead of
`IgnoreParens` here. This has the effect of the warning firing more often
than previously in C code – it now fires as often as it fires in C++ code.
2. Suppress the warning if it would warn on `UNREFERENCED_PARAMETER`.
`UNREFERENCED_PARAMETER` is a commonly used macro on Windows and it happens
to uselessly trigger -Wunused-value. As discussed in the thread
"rfc: winnt.h's UNREFERENCED_PARAMETER() vs clang's -Wunused-value" on
cfe-dev, fix this by special-casing this specific macro. (This costs a string
comparison and some fast-path lexing per warning, but the warning is emitted
rarely. It fires once in Windows.h itself, so this code runs at least once
per TU including Windows.h, but it doesn't run hundreds of times.)
http://reviews.llvm.org/D13969
llvm-svn: 251441
Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.
This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.
Differential Revision: http://reviews.llvm.org/D13795
llvm-svn: 250486
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
llvm-svn: 250090
C allows for some implicit conversions that C++ does not, e.g. void* ->
char*. This patch teaches clang that these conversions are okay when
dealing with overloads in C.
Differential Revision: http://reviews.llvm.org/D13604
llvm-svn: 249995
Summary:
Currently when a function annotated with __attribute__((nonnull)) is called in an unevaluated context with a null argument a -Wnonnull warning is emitted.
This warning seems like a false positive unless the call expression is potentially evaluated. Change this behavior so that the non-null warnings use DiagRuntimeBehavior so they wont emit when they won't be evaluated.
Reviewers: majnemer, rsmith
Subscribers: mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D13408
llvm-svn: 249787
consider the following:
enum E *p;
enum E { e };
The above snippet is not ANSI C because 'enum E' has not bee defined
when we are processing the declaration of 'p'; however, it is a popular
extension to make the above work. This would fail using the Microsoft
enum semantics because the definition of 'E' would implicitly have a
fixed underlying type of 'int' which would trigger diagnostic messages
about a mismatch between the declaration and the definition.
Instead, treat fixed underlying types as not fixed for the purposes of
the diagnostic.
llvm-svn: 249674
Our self hosting buildbots found a few more tests which weren't updated
to reflect that the enum semantics are part of the Microsoft ABI.
llvm-svn: 249670
Enums without an explicit, fixed, underlying type are implicitly given a
fixed 'int' type for ABI compatibility with MSVC. However, we can
enforce the standard-mandated rules on these types as-if we didn't know
this fact if the tag is not part of a definition.
llvm-svn: 249667
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
Diagnose when a pointer to const T is used as the first argument in at atomic
builtin unless that builtin is a load operation. This is already checked for
C11 atomics builtins but not for __atomic ones.
This patch was given the LGTM by rsmith when it was part
of a larger review. (See http://reviews.llvm.org/D10407)
llvm-svn: 249252
Prior to this patch, -Wtautological-overlap-compare would only warn us
if there was a sketchy logical comparison between variables and
IntegerLiterals. This patch makes -Wtautological-overlap-compare aware
of EnumConstantDecls, so it can apply the same logic to them.
llvm-svn: 249053
Several inputs may not refer to one output constraint in inline assembler
insertions, clang was failing on assertion on such test case.
llvm-svn: 248158
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
Previously, in certain cases lax vector conversions could occur between scalar floating-point values and ExtVector types; these conversions would be simple bitcasts. We need to allow them with other vector types to support some common headers, but we don't need them for ExtVector. Preventing them here makes them behave like other operations involving scalars and ExtVectors.
llvm-svn: 247643
George Burgess IV