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
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
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
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
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
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).
llvm-svn: 70868
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
