to call themselves will get the warning:
"Capturing <itself> strongly in this block is likely to
lead to a retain cycle". Cut down on the amount of noise
by noticing that user at some point sets the captured variable
to null in order to release it (and break the cycle).
// rdar://16944538
llvm-svn: 210823
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
llvm-svn: 210137
This allows us to be more careful when dealing with enums whose fixed
underlying type requires special handling in a format string, like
NSInteger.
A refinement of r163266 from a year and a half ago, which added the
special handling for NSInteger and friends in the first place.
<rdar://problem/16616623>
llvm-svn: 209966
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
The conventional form is '<action> to silence this warning'.
Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.
llvm-svn: 209052
Warn on std::abs() with unsigned argument.
Suggest std::abs as replacement for the C absolute value functions.
Suggest C++ headers if the specific std::abs overload is not found.
llvm-svn: 206340
better. This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {} // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
Someone could write:
if (0) {
__c11_atomic_load(ptr, memory_order_release);
}
or the equivalent, which is perfectly valid, so we shouldn't outright reject
invalid orderings on purely static grounds.
rdar://problem/16242991
llvm-svn: 203564
This is a conservative check, because it's valid for the expression to be
non-constant, and in cases like that we just don't know whether it's valid.
rdar://problem/16242991
llvm-svn: 203561
const char *format = "%s";
std::experimental::string_view view = "foo";
printf(format, view);
In this case, not only warn about a class type being used here, but also suggest that calling c_str() might be a good idea.
llvm-svn: 202461
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
llvm-svn: 202216
The warnings fall into three groups.
1) Using an absolute value function of the wrong type, for instance, using the
int absolute value function when the argument is a floating point type.
2) Using the improper sized absolute value function, for instance, using abs
when the argument is a long long. llabs should be used instead.
From these two cases, an implicit conversion will occur which may cause
unexpected behavior. Where possible, suggest the proper absolute value
function to use, and which header to include if the function is not available.
3) Taking the absolute value of an unsigned value. In addition to this warning,
suggest to remove the function call. This usually indicates a logic error
since the programmer assumed negative values would have been possible.
llvm-svn: 202211
Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.
llvm-svn: 202004
Because GCC incorrectly defines _mm_prefetch to take anything that casts
to void*, people have started using that behavior. The previous patch
that made _mm_prefetch actually take a const char * broke compatibility
with existing code. This update to the patch leaves the macro that
defines _mm_prefetch with the (void*) cast when _MSC_VER is not defined.
llvm-svn: 201901
This breaks backwards compatibility with existing code. Previously, this
was defined as
#define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a), 0, (sel)))
Which basically accepts any pointer. Changing this to char* simply
breaks a lot of existing code. I have tried changing char* to
"const void*", which seems to be the right thing as per Intel
specification this should work on basically any pointer. However,
apparently this breaks windows compatibility (because of a conflicting
declaration in windows.h).
So, we probably need to #ifdef this based on whether clang is compiling
for windows. According to Chandler, this might be done by introducing an
additional symbol to a fake type in BuiltinsX86.def and then condition
the type expansion on the platform.
llvm-svn: 201775
This patch adds several built-ins that are required for ms
compatibility. _mm_prefetch must be a built-in because it takes a
compile-time constant argument and our prior approach of using a #define
to the current built-in doesn't work in the presence of re-declaration
of _mm_prefetch. The others can be obtained by including the windows
system headers. If a user includes the windows system headers but not
intrin.h they still need to work and therefore must be built-in because
we don't get a chance to implement them in intrin.h in this case.
llvm-svn: 201734
There are two kinds of automatically generated tests for NEON intrinsics, both
of which can be merged without adversely affecting users.
1. We check that a valid kind of __builtin_neon_XYZ overload is requested (e.g.
we're not asking for a float32x4_t version when it only accepts integers. Since
the __builtin_neon_XYZ intrinsics should only be used in arm_neon.h, relaxing
this test and permitting AArch64 types for AArch32 should not cause a problem.
The extra arm_neon.h definitions should be #ifdefed out anyway.
2. We check that intrinsics which take immediates are actually given
compile-time constants within range. Since all NEON intrinsics should be
backwards compatible, these tests should be identical on AArch64 and AArch32
anyway.
This patch, therefore, merges the separate AArch64 and 32-bit checks.
rdar://problem/16035743
llvm-svn: 201659
Previously, range checking on the __builtin_neon_XYZ_v Clang intrinsics didn't
take account of the type actually passed to the call, which meant a request
like "vext_s16(a, b, 7)" was allowed through (TableGen was conservative and
allowed 0-7 for all types). This caused an assert in the backend because the
lane doesn't make sense.
llvm-svn: 201232
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
Previously, string literals were ignored in all logical expressions. This
reduces it to only ignore in logical and expressions.
assert(0 && "error"); // No warning
assert(0 || "error"); // Warn
Fixes PR17565
llvm-svn: 200056
This involved making CheckReturnStackAddr into a static function, which
is now called by a top-level return value checking routine called
CheckReturnValExpr.
llvm-svn: 199790
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
This allows the following syntax:
void baz(__attribute__((nonnull)) const char *str);
instead of:
void baz(const char *str) __attribute__((nonnull(1)));
This also extends to Objective-C methods.
The checking logic in Sema is not as clean as I would like. Effectively
now we need to check both the FunctionDecl/ObjCMethodDecl and the parameters,
so the point of truth is spread in two places, but the logic isn't that
cumbersome.
Implements <rdar://problem/14691443>.
llvm-svn: 199467
The ABI requires the destructor to be invoked in the callee, but the
standard does not require access checks here so we avoid doing direct
access checks on the destructor.
If we end up needing to define an implicit destructor, we don't skip
access checks for the base class, etc. Those checks are effectively part
of generating the destructor definition, and aren't affected by which TU
the check is performed in.
Differential Revision: http://llvm-reviews.chandlerc.com/D2409
llvm-svn: 199120
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
Thisadds a new warning that warns on code like this:
if (memcmp(a, b, sizeof(a) != 0))
The warning looks like:
test4.cc:5:30: warning: size argument in 'memcmp' call is a comparison [-Wmemsize-comparison]
if (memcmp(a, b, sizeof(a) != 0))
~~~~~~~~~~^~~~
test4.cc:5:7: note: did you mean to compare the result of 'memcmp' instead?
if (memcmp(a, b, sizeof(a) != 0))
^ ~
)
test4.cc:5:20: note: explicitly cast the argument to size_t to silence this warning
if (memcmp(a, b, sizeof(a) != 0))
^
(size_t)( )
1 warning generated.
This found 2 bugs in chromium and has 0 false positives on both chromium and
llvm.
The idea of triggering this warning on a binop in the size argument is due to
rnk.
llvm-svn: 198063
Summary:
MSVC destroys arguments in the callee from left to right. Because C++
objects have to be destroyed in the reverse order of construction, Clang
has to construct arguments from right to left and destroy arguments from
left to right.
This patch fixes the ordering by reversing the order of evaluation of
all call arguments under the MS C++ ABI.
Fixes PR18035.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2275
llvm-svn: 196402
The AST was constructed so that this builtin returned the default BoolTy and
since I'd opted for custom SemaChecking, I should have set it properly at that
point.
This caused an assertion failure when the types didn't match up with what we
generated. This makes it return an IntTy, which is as good as anything.
llvm-svn: 193606
_Bool in C, if the macro is defined. Also teach FixItUtils to look at whether
the macro was defined at the source location for which it is creating a fixit,
rather than looking at whether it's defined *now*. This is especially relevant
for analysis-based warnings which are delayed until end of TU.
llvm-svn: 191057
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
llvm-svn: 190915
I changed the diagnostic printing code because it's probably better
to cut off a digit from DBL_MAX than to print something like
1.300000001 when the user wrote 1.3.
llvm-svn: 189625
Basically, isInMainFile considers line markers, and isWrittenInMainFile
doesn't. Distinguishing between the two is useful when dealing with
files which are preprocessed files or rewritten with -frewrite-includes
(so we don't, for example, print useless warnings).
llvm-svn: 188968
function: it can't be 'void' and it can't be an initializer list. We give a
hard error for these rather than treating them as undefined behavior (we can
and probably should do the same for non-POD types in C++11, but as of this
change we don't).
Slightly rework the checking of variadic arguments in a function with a format
attribute to ensure that certain kinds of format string problem (non-literal
string, too many/too few arguments, ...) don't suppress this error.
llvm-svn: 187735
Patch by Ana Pazos
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
llvm-svn: 187568
Previously a diagnostic was issued, but the code went ahead and built the ShuffleVectorExpr. While I'm here also simplify a couple lines by wrapping the return ExprError around the Diag calls.
llvm-svn: 187344
This adds three overloaded intrinsics to Clang:
T __builtin_arm_ldrex(const volatile T *addr)
int __builtin_arm_strex(T val, volatile T *addr)
void __builtin_arm_clrex()
The intent is that these do what users would expect when given most sensible
types. Currently, "sensible" translates to ints, floats and pointers.
llvm-svn: 186394
& operator (ignoring any overloaded operator& for the type). The purpose of
this builtin is for use in std::addressof, to allow it to be made constexpr;
the existing implementation technique (reinterpret_cast to some reference type,
take address, reinterpert_cast back) does not permit this because
reinterpret_cast between reference types is not permitted in a constant
expression in C++11 onwards.
llvm-svn: 186053
Use UsualArithmeticConversions unconditionally in analysis of
comparisons and conditional operators: the method performs
the usual arithmetic conversions if both sides are arithmetic, and
usual unary conversions if they are not. This is just a cleanup
for conditional operators; for comparisons, it fixes the issue that
we would try to check isArithmetic() on an atomic type.
Also, fix GetExprRange() in SemaChecking.cpp so it deals with variables
of atomic type correctly.
Fixes PR15537.
llvm-svn: 185857
before the value computation of the result. In C, this is implied by there being
a sequence point after their evaluation, and in C++, it's implied by the
side-effects being sequenced before the expressions and statements in the
function body.
llvm-svn: 185282
