__unknown_anytype, and rewrite such message sends correctly.

I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing;  this is clearly just debugger-specific behavior.

llvm-svn: 135051

Make it also available in ObjC++ propeties. Use common code for
objc and objc++ so they don't diverge. // rdar://9740328

llvm-svn: 135050

Re-relax conversion specifier checking for printf format strings and conversion specifiers.  My recent change was a mistake.

llvm-svn: 135048

Fix inversion in argument type checking for format strings with conversion specifiers for character types.

llvm-svn: 135046

them, too.

llvm-svn: 135038

llvm-svn: 135036

and (while I'm at it) teach it to grok the results of simple
assignments.

The first is PR10336.

llvm-svn: 135034

partial destruction.

llvm-svn: 135033

i32.  They almost always end up this way in the end anyway, and if we get
lucky, this avoids generating some bitcasts.

llvm-svn: 135032

like arguments.  Thanks PR10337! :)

llvm-svn: 135030

llvm-svn: 135029

storage duration, then explicitly exempt ownership-qualified
types from it.

llvm-svn: 135028

unrestricted unions, which ended up attempting to initialize objects
in a union (which CodeGen isn't prepared for). Fixes PR9683.

llvm-svn: 135027

Silliness with commas, as reported at http://blog.regehr.org/archives/558 .  As it turns out, this is my fault for not noticing this was an issue when I was looking at this a long time ago. :(

llvm-svn: 135026

which implicitly makes it EH-safe as well.

llvm-svn: 135025

the complete destructor and then invoke the global delete
operator. Previously, we would invoke the deleting destructor, which
calls the wrong delete operator. Fixes PR10341.

llvm-svn: 135021

Correctly set up the list of virtual base classes for a CXXRecordDecl. Previously we got the source range wrong for everything in the virtual bases list.

llvm-svn: 135011

llvm-svn: 135010

llvm-svn: 135004

llvm-svn: 135003

[arcmt] Before applying '__weak' check whether the objc class is annotated with objc_arc_weak_reference_unavailable
or is in a list of classes not supporting 'weak'.

rdar://9489367.

llvm-svn: 135002

Make it also available in ObjC++ propeties. // rdar://9740328

llvm-svn: 135001

of flags.  No functionality change.

llvm-svn: 134997

llvm-svn: 134996

llvm-svn: 134995

block pointers) that don't have any qualification to be POD types. We
were previously considering them to be non-POD types, because this was
convenient in C++ for is_pod-like traits. However, we now end up
inferring lifetime in such cases (template arguments infer __strong),
so it is not necessary.

Moreover, we want rvalues of object type (which have their lifetime
stripped) to be PODs to allow, e.g., va_arg(arglist, id) to function
properly. Fixes <rdar://problem/9758798>.

llvm-svn: 134993

implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771

llvm-svn: 134992

llvm-svn: 134989

and kill a lot of redundant code.

llvm-svn: 134988

dependent. This covers an odd class of types such as

  int (&)[sizeof(sizeof(T() + T()))];

which involve template parameters but, because of some trick typically
involving a form of expression that is never type-dependent, resolve
down to a non-dependent type. Such types need to be mangled
essentially as they were written in the source code (involving
template parameters), rather than via their canonical type.

In general, instantiation-dependent types should be mangled as
they were written in the source. However, since we can't do that now
without non-trivial refactoring of the AST (see the new FIXME), I've
gone for this partial solution: only use the as-written-in-the-source
mangling for these strange types that are instantiation-dependent but
not dependent. This provides better compatibility with previous
incarnations of Clang and with GCC. In the future, we'd like to get
this right.

Fixes <rdar://problem/9663282>.

llvm-svn: 134984

Found by valgrind.

llvm-svn: 134983

StructType::get() and TargetData::getIntPtrType().

llvm-svn: 134982

builds introduced in r134972:

lib/CodeGen/CGExpr.cpp:1294:7: error: no matching function for call to 'EmitBitCastOfLValueToProperType'
lib/CodeGen/CGExpr.cpp:1278:1: note: candidate function not viable: no known conversion from 'CGBuilderTy' (aka 'IRBuilder<false>') to 'llvm::IRBuilder<> &' for 1st argument

This fixes the issue by passing CodeGenFunction on down, and using its
builder directly rather than passing just the builder down.

This may not be the best / cleanest fix, Chris please review. It at
least fixes builds.

llvm-svn: 134977

It would be cool if we could do overload resolution to suggest
the right function, but at least this fixes the crashing.

llvm-svn: 134976

llvm-svn: 134974

isSugared() and desugar() routines previously provided were never
actually called, since the corresponding types
(DependentTypeOfExprType, DependentDecltypeType) don't have
corresponding type classes. Outside of the current (incomplete) patch
I'm working on, I haven't found a way to trigger this problem.

llvm-svn: 134973

uncompleted struct types.  We now do what llvm-gcc does and compile
them into [i8 x 0].  If the type is later completed, we make sure that
it is appropriately cast.

We compile the terrible example to something like this now:

%struct.A = type { i32, i32, i32 }

@g = external global [0 x i8]

define void @_Z1fv() nounwind {
entry:
  call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*))
  ret void
}

declare void @_Z3fooP1A(%struct.A*)

define %struct.A* @_Z2f2v() nounwind {
entry:
  ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1)
}

llvm-svn: 134972

fixes the -m32 build of oggenc.

llvm-svn: 134971

stuff like this:

typedef struct {
 int x, y, z; 
} foo_t;

foo_t g;

into:
%"struct.<anonymous>" = type { i32, i32, i32 }
we now get:
%struct.foo_t = type { i32, i32, i32 }

This doesn't change the behavior of the compiler, but makes the IR much easier to read.

llvm-svn: 134969

llvm-svn: 134967