Unify the BlockDeclRefExpr and DeclRefExpr paths so that
we correctly emit loads of BlockDeclRefExprs even when they
don't qualify as ODR-uses. I think I'm adequately convinced
that BlockDeclRefExpr

Unify the BlockDeclRefExpr and DeclRefExpr paths so that
we correctly emit loads of BlockDeclRefExprs even when they
don't qualify as ODR-uses. I think I'm adequately convinced
that BlockDeclRefExpr can die.

llvm-svn: 152479

show more ...

Add missing code for compound literals of complex type. <rdar://problem/10938628>

llvm-svn: 151549

Generate an AST for the conversion from a lambda closure type to a
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are

Generate an AST for the conversion from a lambda closure type to a
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).

Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.

llvm-svn: 151131

show more ...

Split reinterpret_casts of member pointers out from CK_BitCast; this
is general goodness because representations of member pointers are
not always equivalent across member pointer types on all ABIs
(

Split reinterpret_casts of member pointers out from CK_BitCast; this
is general goodness because representations of member pointers are
not always equivalent across member pointer types on all ABIs
(even though this isn't really standard-endorsed).

Take advantage of the new information to teach IR-generation how
to do these reinterprets in constant initializers. Make sure this
works when intermingled with hierarchy conversions (although
this is not part of our motivating use case). Doing this in the
constant-evaluator would probably have been better, but that would
require a *lot* of extra structure in the representation of
constant member pointers: you'd really have to track an arbitrary
chain of hierarchy conversions and reinterpretations in order to
get this right. Ultimately, this seems less complex. I also
wasn't quite sure how to extend the constant evaluator to handle
foldings that we don't actually want to treat as extended
constant expressions.

llvm-svn: 150551

show more ...

More dead code removal (using -Wunreachable-code)

llvm-svn: 148577

Some improvements to the handling of C11 atomic types:

- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation o

Some improvements to the handling of C11 atomic types:

- 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

show more ...

Revert r147664; it's breaking clang regression tests.

llvm-svn: 147681

Silence GCC warnings.

llvm-svn: 147664

Enter the cleanups for a block outside the enclosing
full-expression. Naturally they're inactive before we enter
the block literal expression. This restores the intended
behavior that blocks belong

Enter the cleanups for a block outside the enclosing
full-expression. Naturally they're inactive before we enter
the block literal expression. This restores the intended
behavior that blocks belong to their enclosing scope.

There's a useful -O0 / compile-time optimization that we're
missing here with activating cleanups following straight-line
code from their inactive beginnings.

llvm-svn: 144268

show more ...

Rip out CK_GetObjCProperty.

llvm-svn: 143910

Rip the ObjCPropertyRef l-value kind out of IR-generation.

llvm-svn: 143908

Change the AST representation of operations on Objective-C
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressio

Change the AST representation of operations on Objective-C
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

show more ...

Restore r142914 and r142915, now with missing file and apparent
GCC compiler workaround.

llvm-svn: 142931

Revert r142914 and r142915, due to possibly missing file.

r142914: "Introduce a placeholder type for "pseudo object""
r142915: "Pull the pseudo-object stuff into its own file."
llvm-svn: 142921

Introduce a placeholder type for "pseudo object"
expressions: expressions which refer to a logical rather
than a physical l-value, where the logical object is
actually accessed via custom getter/sett

Introduce a placeholder type for "pseudo object"
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

show more ...

Initial implementation of __atomic_* (everything except __atomic_is_lock_free).

llvm-svn: 141632

de-tmpify clang.

llvm-svn: 140637

Removing a bunch of dead returns/breaks after llvm_unreachables.

llvm-svn: 140407

Switch assert(0/false) llvm_unreachable.

llvm-svn: 140367

Add list initialization for complex numbers in C. Essentially, this allows "_Complex float x = {1.0f, 2.0f};". See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem

Add list initialization for complex numbers in C. Essentially, this allows "_Complex float x = {1.0f, 2.0f};". See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem/9397672>.

llvm-svn: 140090

show more ...

Rename the ARC cast kinds to start with "ARC".

llvm-svn: 139466

When converting a block pointer to an Objective-C pointer type, extend
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 no

When converting a block pointer to an Objective-C pointer type, extend
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

show more ...

Give conversions of block pointers to ObjC pointers a different cast kind
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr th

Give conversions of block pointers to ObjC pointers a different cast kind
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

show more ...

blocks: Support capturing complex variable in block.
// rdar://10033896

llvm-svn: 139041

revert patch in r139020

llvm-svn: 139029