| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
pathological cases.
PR18905.
llvm-svn: 201795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
internal discussions. // rdar://16006401
llvm-svn: 200986
|
|
|
|
|
|
|
| |
reference (or pointer) to a variable from the closure object or from the
surrounding function scope.
llvm-svn: 200494
|
|
|
|
|
|
|
|
|
| |
cast into a boolean true value. This warning will catch code like:
if (@0) {}
if (@"foo") {}
llvm-svn: 200356
|
|
|
|
|
|
|
| |
throw-expression, the result is also a glvalue and isn't unnecessarily coerced
to a prvalue.
llvm-svn: 200189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
in Sema::CheckReturnValExpr. Add the missing handling of value-dependent expressions for returns_nonnull.
llvm-svn: 199989
|
|
|
|
|
|
|
|
|
|
| |
'returns_nonnull'.
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
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 199465
|
|
|
|
| |
llvm-svn: 199464
|
|
|
|
|
|
|
|
| |
valid.
This was caught by running test/SemaCXX/destructor.cpp in MS ABI mode.
llvm-svn: 199128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
the warning will not trigger on code protected by compile time checks.
llvm-svn: 198913
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 198392
|
|
|
|
|
|
|
|
| |
This better describes what the function does.
Cleanup only.
llvm-svn: 198127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 196888
|
|
|
|
| |
llvm-svn: 196510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 194660
|
|
|
|
| |
llvm-svn: 194513
|
|
|
|
| |
llvm-svn: 194197
|
|
|
|
|
|
| |
checking an expression for constant overflow.
llvm-svn: 194099
|
|
|
|
| |
llvm-svn: 193888
|
|
|
|
| |
llvm-svn: 193887
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
attributes when such methods are actually envoked in message
expression. // rdar://15242010
llvm-svn: 193003
|
|
|
|
|
|
|
|
| |
that can represent unicode characters
Fixes <rdar://problem/13991617>.
llvm-svn: 192673
|
|
|
|
|
|
|
|
|
|
| |
OpaqueValueExprs.
Fixes a false positive with -Wconversion involving Objective-C properties.
Fixes <rdar://problem/14415662>.
llvm-svn: 192611
|
|
|
|
|
|
|
|
|
| |
_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
|
|
|
|
|
|
| |
PR17123.
llvm-svn: 190484
|
|
|
|
|
|
| |
StringArgument since that is a more accurate modeling.
llvm-svn: 189851
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 189112
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
in include/clang/Basic/LLVM.h.
llvm-svn: 188138
|
|
|
|
| |
llvm-svn: 188063
|
|
|
|
| |
llvm-svn: 187975
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
undefined element value to match IR capabilities.
llvm-svn: 187694
|