- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
With that done, remove a bunch of buggy code from CGExprConstant for handling scalar expressions which is no longer necessary.
Fixes PR11705.
llvm-svn: 147561
The motivation here is a "clever" implementation of strncmp(), which peels the first few comparisons via chained conditional expressions which ensure that the input arrays are known at compile time to be sufficiently large.
llvm-svn: 146430
in addition to underlying type.
For example, the warning for printf("%zu", 42.0);
changes from "conversion specifies type 'unsigned long'" to "conversion
specifies type 'size_t' (aka 'unsigned long')"
(This is a second attempt after r145697, which got reverted.)
llvm-svn: 146032
methods) to bool. E.g.
void foo() {}
if (f) { ... // <- Warns here.
}
Only applies to non-weak functions, and does not apply if the function address
is taken explicitly with the addr-of operator.
llvm-svn: 145849
For example, the warning for printf("%zu", 42.0);
changes from "conversion specifies type 'unsigned long'" to "conversion
specifies type 'size_t' (aka 'unsigned long')"
llvm-svn: 145697
consider the _<width> variants as well, which we'll see if we're
performing the type checking in a template instantiation where the
call expression itself was originally not type-dependent. Fixes
PR11411.
llvm-svn: 145248
The code for checking Neon builtin pointer argument types was assuming that
there would only be one pointer argument. But, for vld2-4 builtins, the first
argument is a special sret pointer where the result will be stored. So,
instead of scanning all the arguments to find a pointer, have TableGen figure
out the index of the pointer argument that needs checking. That's better than
scanning all the arguments regardless. <rdar://problem/10448804>
llvm-svn: 144834
which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.
llvm-svn: 144110
The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.
llvm-svn: 144075
This patch just adds a simple NeonTypeFlags class to replace the various
hardcoded constants that had been used until now. Unfortunately I couldn't
figure out a good way to avoid duplicating that class between clang and
TableGen, but since it's small and rarely changes, that's not so bad.
llvm-svn: 144054
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
llvm-svn: 143867
implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.
llvm-svn: 143263
string is part of the function call, then there is no difference. If the
format string is not, the warning will point to the call site and a note
will point to where the format string is.
Fix-it hints for strings are moved to the note if a note is emitted. This will
prevent changes to format strings that may be used in multiple places.
llvm-svn: 143168
expressions: expressions which refer to a logical rather
than a physical l-value, where the logical object is
actually accessed via custom getter/setter code.
A subsequent patch will generalize the AST for these
so that arbitrary "implementing" sub-expressions can
be provided.
Right now the only client is ObjC properties, but
this should be generalizable to similar language
features, e.g. Managed C++'s __property methods.
llvm-svn: 142914
For PR11152. Make PrintSpecifier::fixType() suggest "%zu" for size_t, etc.
rather than looking at the underlying type and suggesting "%llu" or other
platform-specific length modifiers. Applies to C99 and C++11.
llvm-svn: 142342
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
C-style and functional casts are built in SemaCXXCast.cpp.
Introduce a helper class to encapsulate most of the random
state being passed around, at least one level down.
llvm-svn: 141170
is cast to a boolean. An exception has been made for string literals in
logical expressions to allow the common case of use in assert statements.
bool x;
x = "hi"; // Warn here
void foo(bool x);
foo("hi"); // Warn here
assert(0 && "error");
assert("error); // Warn here
llvm-svn: 140405
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
case situations with the unary operators & and *. Also extend the array bounds
checking to work with pointer arithmetic; the pointer arithemtic checking can
be turned on using -Warray-bounds-pointer-arithmetic.
The changes to where CheckArrayAccess gets called is based on some trial &
error and a bunch of digging through source code and gdb backtraces in order
to have the check performed under as many situations as possible (such as for
variable initializers, arguments to function calls, and within conditional in
addition to the simpler cases of the operands to binary and unary operator)
while not being called--and triggering warnings--more than once for a given
ArraySubscriptExpr.
llvm-svn: 136997
arrays. This now suppresses the warning only in the case of
a one-element array as the last field in a struct where the array size
is a literal '1' rather than any macro expansion or template parameter.
This doesn't distinguish between the language standard in use to allow
code which dates from C89 era to compile without the warning even in C99
and C++ builds. We could add a separate warning (under a different flag)
with fixit hints to switch to a flexible array, but its not clear that
this would be desirable. Much of the code using this idiom is striving
for maximum portability.
Tests were also fleshed out a bit, and the diagnostic itself tweaked to
be more pretty w.r.t. single elment arrays. This is more ugly than
I would like due to APInt's not being supported by the diagnostic
rendering engine.
A pseudo-patch for this was proposed by Nicola Gigante, but I reworked
it both for several correctness issues and for code style.
Sorry this was so long in coming.
llvm-svn: 136965
1-element character arrays which are serving as flexible arrays. This is
the initial step, which is to restrict the 1-element array whitelist to
arrays that are member declarations. I'll refine it from here based on
the proposed patch.
llvm-svn: 136964
has a single element. This disables the warning in cases where
there is a clear bug, but this is really rare (who uses arrays
with one element?) and it also silences a large class of false
positive issues with C89 code that is using tail padding in structs.
A better version of this patch would detect when an array is in
a tail position in a struct, but at least patch fixes the huge
false positives that are hitting postgres and other code.
llvm-svn: 136724
and to work with pointer arithmetic in addition to array indexing.
The new pointer arithmetic porition of the array bounds checking can be
turned on by -Warray-bounds-pointer-arithmetic (and is off by default).
llvm-svn: 136046
where we have an immediate need of a retained value.
As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain. This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.
rdar://problem/9504800
llvm-svn: 134605
MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given
const int& r = 1.0;
The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value.
IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.
llvm-svn: 133521
__builtin_ versions of these functions as well as the normal function
versions, so that it works on platforms where memset/memcpy/memmove
are macros that map down to the builtins (e.g., Darwin). Fixes
<rdar://problem/9372688>.
llvm-svn: 133173
and the programmer intended to write 'sizeof(*p)'. There are several
elements to the new version:
1) The actual expressions are compared in order to more accurately flag
the case where the pattern that works for an array has been used, or
a '*' has been omitted.
2) Only do a loose type-based check for record types. This prevents us
from warning when we happen to be copying around chunks of data the
size of a pointer and the pointer types for the sizeof and
source/dest match.
3) Move all the diagnostics behind the runtime diagnostic filter. Not
sure this is really important for this particular diagnostic, but
almost everything else in SemaChecking.cpp does so.
4) Make the wording of the diagnostic more precise and informative. At
least to my eyes.
5) Provide highlighting for the two expressions which had the unexpected
similarity.
6) Place this diagnostic under a flag: -Wsizeof-pointer-memaccess
This uses the Stmt::Profile system for computing #1. Because of the
potential cost, this is guarded by the warning flag. I'd be interested
in feedback on how bad this is in practice; I would expect it to be
quite cheap in practice. Ideas for a cheaper / better way to do this are
also welcome.
The diagnostic wording could likely use some further wordsmithing.
Suggestions welcome here. The goals I had were to: clarify that its the
interaction of 'memset' and 'sizeof' and give more reasonable
suggestions for a resolution.
An open question is whether these diagnostics should have the note
attached for silencing by casting the dest/source pointer to void*.
llvm-svn: 133155
argument types for mem{set,cpy,move}. Character pointers, much like void
pointers, often point to generic "memory", so trying to check whether
they match the type of the argument to 'sizeof' (or other checks) is
unproductive and often results in false positives.
Nico, please review; does this miss any of the bugs you were trying to
find with this warning? The array test case you had should be caught by
the array-specific sizeof warning I think.
llvm-svn: 133136
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
David Chisnall