llvm-svn: 71585

llvm-svn: 71583

selectors which need use Nonfrgile API for
message dispatch.

llvm-svn: 71578

only and used in class imllementations (objc2 Nonfragile ABI specific).

llvm-svn: 71571

don't need special treatment for unions.

llvm-svn: 71559

register.
 - Merge algorithm was returning MEMORY as it should.

llvm-svn: 71556

Factor code that's common to EmitCXXMemberCallExpr and EmitCXXConstructorCall out into a EmitCXXMemberCall function.

llvm-svn: 71514

spotted by Eli!

llvm-svn: 71490

message dispage API for all but a few messages. This is 
a runtime performance improvement and there is not meant
to be a functional change.

llvm-svn: 71467

llvm-svn: 71461

llvm-svn: 71451

llvm-svn: 71405

LLVM.

llvm-svn: 71350

 - {return-types,single-args}-{32,64} pass the first 1k ABI tests with
   bit-fields enabled.

llvm-svn: 71272

to use a wide enough type. This might be wider than the "single
element"'s type in the presence of padding bit-fields.
 - Darwin x86_32 now passes the first 1k ABI tests with bit-field
   generation enabled.

llvm-svn: 71270

element" structures.

llvm-svn: 71266

 - This turns out to be a no-op now that most of the handling for
   everything else is in place.

llvm-svn: 71261

 - This eliminates 5/1000 failures on return-types-32, on the current
   ABITest config.

llvm-svn: 71250

llvm-svn: 71227

"This patch fixes message sends to super in categories for the GNU runtime.  This used to work, but I broke it when I modified the code to emit the same thing as GCC for message sends to super in classes."

Patch by David Chisnall!

llvm-svn: 71220

semantic rules that gcc and icc use.  This implements the variadic
and concrete versions as builtins and has sema do the 
disambiguation.  There are probably a bunch of details to finish up
but this seems like a large monotonic step forward :)

llvm-svn: 71212

"This patch is a first pass at adding support for exceptions for the GNU runtime.  There are a few limitations at present:

- @synchronized() is not yet supported at all.  gcc currently emits calls to runtime library functions that don't exist for this directive.

- Only id @catch statements are currently working.  This is enough for NS_DURING and friends, but I need to spend more time reading the output from gcc -S to work out how it finds the class pointer to make arbitrary class type catch statements work.

- I've tested it with a few common cases[1] and the clang test suite (which doesn't test exceptions for the GNU runtime, but shows I haven't broken anything else), but there are probably a lot of cases I've missed."

Patch by David Chisnall!

llvm-svn: 71198

llvm-svn: 71194

Patch by David Chisnall.

llvm-svn: 71023

to go back and clean up existing uses of the bitcasted function.  This
is not just an optimization: it is required for correctness to get
always inline functions to work, see testcases in function-attributes.c.

llvm-svn: 70971

types.  In this case, it was objc_selector and objc_class.  This fixes
rdar://6852754 - clang sometimes generates incorrect/unknown file/line info for DW_TAG__structure_type dies

llvm-svn: 70969

DIEs.  We were generating a loc with line of 0 and a file.
These tags do not need locations at all, just remove it.
this fixes rdar://6852792 - Clang generates incorrect (and unnecessary) file and line info for DW_TAG_inheritance dies

llvm-svn: 70966

in ObjC) to not emit file/line location information.  Previously
we would output a file with bogus line information.  This fixes:
rdar://6852814 - Clang generates incorrect file & line info for automatic/understood formal parameters for objc-programs

llvm-svn: 70965

Refactor global decls to hold either a regular Decl or a CXXConstructorDecl + ctor type or a CXXDestructorDecl + dtor type.

llvm-svn: 70962

llvm-svn: 70951

objc_assign_global API when assigning to global
objective-c object pointer.

llvm-svn: 70939

compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
 - Also, we now report the size info for an empty class like gcc (as
   the offset of the start, not as 0, 0).

 - Add a few more test cases we were mishandling before (padding bit
   field at end of struct, for example).

llvm-svn: 70938

layout.
 - This is much simpler / more efficient.

 - This also properly computes the size in the presence of bit-fields.

llvm-svn: 70916

function calls.  For a program like this:

#include <stdio.h>
static __inline__ __attribute__((always_inline)) 
int bar(int x) { return 4; }
int main() { 
  int X = bar(4);
  printf("%d\n", X);
}

clang was not outputing any debug info for the body of main().  This is
because the backend is getting confused by the region_start/end that clang
is emitting for block scopes.  For now, just disable these (matching llvm-gcc),
this stuff is in progress of rework anyway.

llvm-svn: 70889

"The attached diff fixes the //FIXME in message send to super.  This should now be faster, and works in the presence of class posing.  This is now the same approach as used in GCC (the earlier code was a quick hack to get something working)."

Patch by David Chisnall!

llvm-svn: 70877

The attached diff fixes the //FIXME in message send to super.  This
should now be faster, and works in the presence of class posing.  This
is now the same approach as used in GCC (the earlier code was a quick
hack to get something working).

llvm-svn: 70868

llvm-svn: 70835

llvm-svn: 70825

hopefully, this fixes PR4144 without any regressions.

llvm-svn: 70823

via CollectObjCIvars.
 - In places where we need them, we should have the implementation and
   access the properties through it.

This is a fairly substantial functionality change: 
 1. @encode no longer encodes synthesized ivars, ever.

 2. The ivar layout bitmap no longer encodes information for
    synthesized ivars in superclasses. Well, actually I had already
    broken that, but it is intentional now.

We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.

Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.

I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.

llvm-svn: 70822