llvm-svn: 146857

declaration for the type then go ahead and use that, it's still smaller
than creating an all new derived type.

Part of rdar://10335756 and others.

llvm-svn: 146779

classes.

Part of rdar://10520586 and a couple others.

llvm-svn: 146778

llvm-svn: 146705

declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"

llvm-svn: 146679

to declaresSameEntity(), as a baby step toward tracking forward
declarations of Objective-C classes precisely. Part of
<rdar://problem/10583531>.

llvm-svn: 146618

llvm-svn: 146530

Make CGRecordLayoutBuilder correctly switch over to a packed class when a class has a base whose alignment will break the class layout.  <rdar://problem/10551376>.

llvm-svn: 146443

llvm-svn: 146441

llvm-svn: 146413

setting the is_zero_undef flag appropriately to true as that matches the
semantics of these GCC builtins.

This is the Clang side of r146357 in LLVM.

llvm-svn: 146358

Silences valgrind warnings about uninitalized alignment values.

llvm-svn: 146342

llvm-svn: 146291

llvm-svn: 146202

llvm-svn: 146189

Make sure we correctly zero-initialize unions containing a pointer to data member as the first field.  PR11487.

llvm-svn: 146009

realignment, even with locals with alignment exceeding the ABI guarantee.

llvm-svn: 145909

llvm-svn: 145905

backend options are gone.

llvm-svn: 145868

Make EmitAggregateCopy take an alignment argument.  Make EmitFinalDestCopy pass in the correct alignment when known.

The test includes a FIXME for a related case involving calls; it's a bit more complicated to fix because the RValue class doesn't keep track of alignment.

<rdar://problem/10463337>
  

llvm-svn: 145862

llvm-svn: 145753

llvm-svn: 145747

llvm-svn: 145741

Track alignment in AggValueSlot.  No functional change in this patch, but I'll be introducing uses of the specified alignment soon.

llvm-svn: 145736

  __import_module__ std.vector;

in the AST.

llvm-svn: 145725

llvm-svn: 145715

mutable member and a constant initializer. We'd previously promoted such
variables to global constants, resulting in nasal demons if the mutable member
was modified.

This is only a temporary fix. The subtle interplay between isConstantInitializer
and CGExprConstant is very bug-prone; there are some other issues in this area
which I will be addressing in subsequent, more major reworking of this code.

llvm-svn: 145654

When we're passing a vector with an illegal type through memory on x86-64, use byval so we're sure the backend does the right thing.  Fixes va_arg with illegal vectors and an obscure ABI mismatch with __m64 vectors.

llvm-svn: 145652

old dispatch mechanism when I introduced the new one.

llvm-svn: 145609

Don't use a varargs convention for calls unprototyped functions where one of the arguments is an AVX vector.

llvm-svn: 145574

library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).

llvm-svn: 145538

llvm-svn: 145531

The new metadata are method @encode strings with additional data.

1. Each Objective-C object is marked with its class name and protocol names.
The same is done for property @encode already.

2. Each block object is marked with its function prototype's @encoding. For
example, a method parameter that is a block object that itself returns void
and takes an int would look like:
    @?<v@?i>

These new method @encode strings are stored in a single array pointed to by structs protocol_t and objc_protocol_ext.

Patch provided by Greg Parker!

llvm-svn: 145469

for the structure type.

rdar://10499337

llvm-svn: 145461

llvm-svn: 145399

attribute. This prevents the stack slot allocator from coming along and using a
stack which it thinks is available but isn't.
<rdar://problem/10492556>

llvm-svn: 145332

Correct the code generation for function arguments of vec3 types on x86_64 when they are greater than 128 bits. This was incorrectly coercing things like long3 into a double2.
Add test case.

llvm-svn: 145312

llvm-svn: 145227

llvm-svn: 145211

llvm-svn: 145209