support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.

This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.

llvm-svn: 102071

 - This fixes the last known ABI issues with ARM/APCS.

 - I've run the first 1k ABITests with '--no-unsigned --no-vector --no-complex'
   on {armv6, armv7} x {-mno-thumb, -mthumb}, and the first 10k tests for armv7
   -mthumb, for both function return types and single argument calls. These all
   pass now (they failed horribly before without --no-bitfield).

llvm-svn: 102070

immediately narrowed the access size. Fix this (and previous case) by just
choosing a better access size up-front.

llvm-svn: 102068

we have to narrow the access side immediately (can happen with packed,
-fno-bitfield-type-align).

llvm-svn: 102067

look for the const on the base type rather than on the top-level
type. Fixes PR6495 properly.

llvm-svn: 102066

elaborated-type-specifiers. Patch by Enea Zaffanella!

llvm-svn: 102065

llvm-svn: 102064

llvm-svn: 102063

llvm-svn: 102062

llvm-svn: 102061

Rewording the "generated debug information" paragraph in the "Interpreter and JIT Improvements" section of the release notes.

llvm-svn: 102060

Reworking the wording of the "target data string" paragraph in the "Optimizer Improvments" section of the release notes.

llvm-svn: 102059

llvm-svn: 102057

llvm-svn: 102056

llvm-svn: 102055

llvm-svn: 102054

llvm-svn: 102053

llvm-svn: 102052

llvm-svn: 102051

llvm-svn: 102050

llvm-svn: 102049

makes it impossible to check labels.

llvm-svn: 102048

llvm-svn: 102047

llvm-svn: 102046

IRgen: Rewrite bit-field access policy to not access data beyond the bounds of the structure, which we also now verify as part of the post-layout consistency checks.
 - This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align.

 - Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues.

 - Review appreciated.

llvm-svn: 102045

llvm-svn: 102044

llvm-svn: 102043

assertion failures in extreme cases.

llvm-svn: 102042

llvm-svn: 102041

llvm-svn: 102040

in a throw expression.  Use EmitAnyExprToMem to emit the throw expression,
which magically elides the final copy-constructor call (which raises a new
strict-compliance bug, but baby steps).  Give __cxa_throw a destructor pointer
if the exception type has a non-trivial destructor.

llvm-svn: 102039

method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:

t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
      type 'int *' [-pedantic]
  f(long_ptr);
    ^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
            ^

llvm-svn: 102038

llvm-svn: 102037

the alignment is a power of 2, even in the esoteric case of a
vector element which does not have a power-of-2 sizeof value.

llvm-svn: 102036

during message sends) over to the new initialization code and away
from the C-only CheckSingleAssignmentConstraints. The enables the use
of C++ types in method parameters and message arguments, as well as
unifying more initialiation code overall.

llvm-svn: 102035

This actually makes everything slower, but the plan is to have isel add <kill>
flags the way it is already adding <dead> flags. Then LiveVariables can be
removed again.

When ignoring the time spent in LiveVariables, -regalloc=fast is now twice as
fast as -regalloc=local.

llvm-svn: 102034

llvm-svn: 102033

llvm-svn: 102032

Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because

  (1) The receiver of an instance message can be a qualified name such
  as ::I or identity<I>::type.
  (2) Expressions in C++ can start with a type.

The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.

This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,

  [typename compute_receiver_type<T>::type method];

Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,

  typedef typename computed_receiver_type<T>::type Computed;
  [Computed method];

so this is merely a convenience.

Note also that message sends still cannot involve dependent types or
values.

llvm-svn: 102031

llvm-svn: 102030