llvm-svn: 102883

llvm-svn: 102882

llvm-svn: 102881

llvm-svn: 102880

llvm-svn: 102871

llvm-svn: 102870

llvm-svn: 102863

llvm-svn: 102862

assignment operators. 

Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.

This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:

  - For a class subobject, call the appropriate copy-assignment
    operator, after overload resolution has determined what that is.
  - For an array of scalar types or an array of class types that have
    trivial copy assignment operators, construct a call to
    __builtin_memcpy.
  - For an array of class types with non-trivial copy assignment
    operators, synthesize a (possibly nested!) for loop whose inner
    statement calls the copy constructor.
  - For a scalar type, use built-in assignment.

This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.

Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.

llvm-svn: 102853

llvm-svn: 102849

llvm-svn: 102848

llvm-svn: 102846

llvm-svn: 102845

llvm-svn: 102842

llvm-svn: 102839

llvm-svn: 102837

Used this in CGObjCGNU to attach metadata about message sends to permit speculative inlining.

llvm-svn: 102833

access.  Fixes an assertion.

Fixes rdar://problem/7927811.  Too lazy to reduce a test case.

llvm-svn: 102776

llvm-svn: 102747

llvm-svn: 102711

a class with virtual bases.  Just a patch until Sema starts (correctly) doing
most of this analysis.

Fixes PR 6622.

llvm-svn: 102692

when used by the exceptions routines.  Fixes PR 6974.

llvm-svn: 102684

might not have been an insertion block set at start.  Fixes PR6975.

llvm-svn: 102677

llvm-svn: 102676

llvm-svn: 102674

llvm::GLobalVariable name may not match user visibile name for function static variables.

llvm-svn: 102644

IRgen/NeXT: Put the synthesized _objc_super, _message_ref_t decls in a valid DeclContext, to satisfy the invariants that should hold on a RecordDecl.

llvm-svn: 102624

of c++ objects (NeXt runtime).
radar 7900343.

llvm-svn: 102546

Amadini.

This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.

OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.

There are two major caveats to this patch:

  1) CodeGen cannot handle the case where __builtin_offsetof is not a
  constant expression, so it produces an error. So, to avoid
  regressing in C, we retain the old UnaryOperator-based
  __builtin_offsetof implementation in C while using the shiny new
  OffsetOfExpr implementation in C++. The old implementation can go
  away once we have proper CodeGen support for this case, which we
  expect won't cause much trouble in C++.

  2) __builtin_offsetof doesn't work well with non-POD class types,
  particularly when the designated field is found within a base
  class. I will address this in a subsequent patch.

Fixes PR5880 and a bunch of assertions when building Boost.Python
tests. 

llvm-svn: 102542

ivar class objects (NeXt runtime).
(radar 7900343).

llvm-svn: 102533

Changed signature of GenerateMessageSend() function to pass the ObjCInterfaceDecl for class messages and removed the boolean IsClassMessage argument, which wasn't used anywhere.

Emitted some metadata on message sends to allow a later pass to do some speculative inlining of class methods (GNU runtime).  Speculative inlining of instance methods requires type feedback to be useful (work in progress), but for class methods it works quite nicely.  

llvm-svn: 102514

llvm-svn: 102499

llvm-svn: 102497

T::template apply<U>), handling a few cases where we previously failed
and performing substitutions on such dependent names. Fixes a crash in
Boost.PropertyTree.

llvm-svn: 102490

incomplete type.  Fixes PR6911.

llvm-svn: 102473

llvm-svn: 102459

This works around stack corruption / crashes resulting from PR6944, and also
works around people who expect 'what works on my machine' to work everywhere
(GCC crashes in a number of cases on SPARC that should now work correctly with
clang).

llvm-svn: 102430

llvm-svn: 102429

of a class template or class template partial specialization.  That is to
say, in
  template <class T> class A { ... };
or
  template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context.  This allows us to track the
current instantiation appropriately even inside AST routines.  It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).

llvm-svn: 102407

llvm-svn: 102398