- 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
was constructed, e.g. for a property access.
This allows the selector identifier locations machinery for ObjCMessageExpr
to function correctly, in that there are not real locations to handle/report for
such a message.
llvm-svn: 148013
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
evaluator into constant initializer handling / IRGen. The practical consequence
of this is that the bitcast now lives in the constant's definition, rather than
in its uses.
The code in the constant expression evaluator was producing vectors of the wrong
type and size (and possibly of the wrong value for a big-endian int-to-vector
bitcast). We were getting away with this only because we don't yet support
constant-folding of any expressions which inspect vector values.
llvm-svn: 145981
expression evaluation:
- When folding a non-value-dependent expression, we may try to use the
initializer of a value-dependent variable. If that happens, give up.
- In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
is of integral or enumeration type (a reference isn't OK!)
- In C++11, DeclRefExprs for objects of const literal type initialized with
value-dependent expressions are themselves value-dependent.
- So are references initialized with value-dependent expressions (though this
case is missing from the C++11 standard, along with many others).
llvm-svn: 144056
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
- 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
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: [foo first:1 second:2]
-With a space between the arguments: [foo first: 1 second: 2]
-For nullary selectors, immediately before ']': [foo release]
In such cases we infer the locations instead of storing them.
llvm-svn: 140987
We were failing to set source locations and ranges in isUnusedResultAWarning
for CXXOperatorCallExprs, leading to an "expression result unused" warning
with absolutely no context if the expression was inside a macro.
llvm-svn: 140036
to find the called declaration. Explicit casts can radically
change the semantics of a call, and it's no longer really a
builtin call any more than it would be a builtin call if you stored
the function pointer into a variable and called that.
llvm-svn: 139659
the lifetime of the block by copying it to the heap, or else we'll get
a dangling reference because the code working with the non-block-typed
object will not know it needs to copy.
There is some danger here, e.g. with assigning a block literal to an
unsafe variable, but, well, it's an unsafe variable.
llvm-svn: 139451
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr that strictly determine
which cast kind is used for which kind of bit cast.
llvm-svn: 139352
to look through SubstNonTypeTemplateParmExprs. Then, update the IR
generation of CallExprs to actually use CallExpr::getCalleeDecl()
rather than attempting to mimick its behavior (badly).
Fixes <rdar://problem/10063539>.
llvm-svn: 139185
even when overloaded and user-defined. These operators are both more
valuable to warn on (due to likely typos) and extremely unlikely to be
reasonable for use to trigger side-effects.
llvm-svn: 137823
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
type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).
When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.
In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,
template<unsigned> struct A { };
template<typename T>
void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
template void f<int>(A<sizeof(sizeof(int))>);
and therefore get the wrong answer.
llvm-svn: 134225
Matt Beaumont-Gay