block-literal initializer expression causes IRgen to crash.
This patch fixes by saving it in StaticLocalDecl map
already used for such purposes. (radar 8390455).
llvm-svn: 113307
using the same methods as used for normal structures.
- This fixes problems with reading past the end of the structure and with
handling straddled bit-field access.
llvm-svn: 112914
instead of _Unwind_Resume. With SJLJ exceptions, this is spelled
"_Unwind_SjLj_Resume_or_Rethrow", not "_Unwind_SjLj_Resume", which has
significantly different semantics.
We should actually never be generating a call to _Unwind_SjLj_Resume directly;
even if we were generating true cleanups (which we aren't because of the
horrible hack), we should be calling __cxa_end_cleanup() on ARM. I
haven't implemented this because there's little point as long as the HH is
present.
I believe this fixes <rdar://problem/8281377>.
llvm-svn: 110851
where we weren't accounting for the possibility that a @finally block might
have internal cleanups and therefore might write to the cleanup destination slot.
Fixes <rdar://problem/8293901>.
llvm-svn: 110760
ObjC exceptions:
- don't enter a try for the catch blocks unless there's a finally
- put the setjmp buffer in the locals set for liveness reasons
- dump the sync object into an alloca in the locals set for liveness reasons
Some of this can go away if the backend starts to properly calculate liveness
in the presence of setjmp (which would also be a *much* stabler solution).
llvm-svn: 110188
the magic of inline assembly. Essentially we use read and write hazards
on the set of local variables to force flushing locals to memory
immediately before any protected calls and to inhibit optimizing locals
across the setjmp->catch edge. Fixes rdar://problem/8160285
llvm-svn: 109960
sections on", this change uncovered a possible linker bug which resulted in the
wrong messages getting dispatched. Backing this out while we investigate...
llvm-svn: 109817
use of property-dot syntax using 'super' as receiver
is 'void'. This fixes a bug in generating correct
API for setter call. Fixes radar 8203426.
llvm-svn: 109297
mostly in avoiding unnecessary work at compile time but also in producing more
sensible block orderings.
Move the destructor cleanups for local variables over to use lazy cleanups.
Eventually all cleanups will do this; for now we have some awkward code
duplication.
Tell IR generation just to never produce landing pads in -fno-exceptions.
This is a much more comprehensive solution to a problem which previously was
half-solved by checks in most cleanup-generation spots.
llvm-svn: 108270
self-host. Hopefully these results hold up on different platforms.
I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions. Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.
Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former. Remove the need to track which cleanup scope a block is associated
with.
Document a lot of previously poorly-understood (by me, at least) behavior.
The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work. Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however. The HH is an unfortunate requirement of LLVM's EH IR.
llvm-svn: 107631
complex values either. Previously we did this properly for regular assignment,
but not for compound assignment.
- Also, tidy up assignment code a bit to look more like the scalar path.
llvm-svn: 107217
would trigger an extra method call).
- While in the area, I also changed Clang to not emit an unnecessary load from
'x' in cases like 'y = (x = 1)'.
llvm-svn: 107210
'self' variable arising from uses of the 'super' keyword. Also reorganize
some code so that BlockInfo (now CGBlockInfo) can be opaque outside of
CGBlocks.cpp.
Fixes rdar://problem/8010633.
llvm-svn: 104312
user directive is needed to force a property implementation.
It is decided based on those propeties which are declared in
the class (or in its protocols) but not those which must be
default implemented by one of its super classes. Implements radar 7923851.
llvm-svn: 103787
- Fix some places that had the alignment hard coded.
- Use ABI type alignment, not preferred type alignment -- neither of this is exactly right, as we really want the C type alignment as required by the runtime, but the ABI alignment is a more correct choice.
This should be equivalent for x86_64, but fixes the alignment for ARM.
llvm-svn: 102314
- Replace -cc1 level -fobjc-legacy-dispatch with -fobjc-dispatch-method={legacy,non-legacy,mixed}.
- Lift "mixed" vs "non-mixed" policy choice up to driver level, instead of being buried in CGObjCMac.cpp.
- No intended functionality change.
llvm-svn: 102255
This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525. There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.
llvm-svn: 101877
a common source of oddities and, in theory, removes some redundant ABI
computations. Also fixes a miscompile I introduced yesterday by refactoring
some code and causing a slightly different code path to be taken that
didn't perform *parameter* type canonicalization, just normal type
canonicalization; this in turn caused a bit of ABI code to misfire because
it was looking for 'double' or 'float' but received 'const float'.
llvm-svn: 97030
(http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091214/092780.html)
The instruction fixes were checked and approved by Chris Lattner, but
these testcase fixes are mine; please yell at me if there are any
problems with either.
* PR5050-constructor-conversion.cpp
* array-construction.cpp
* constructor-conversion.cpp
* cast-conversion.cpp
* constructor-default-arg.cpp
* derived-to-base-conv.cpp
* ptr-to-member-function.cpp
* call-arg-zero-temp.cpp
* default-destructor-synthesis.cpp
* global-array-destruction.cpp
* array-operator-delete-call.cpp
* decl-ref-init.cpp
* default-constructor-for-members.cpp
* convert-to-fptr.cpp
* constructor-for-array-members.cpp
* conversion-function.cpp
* objc-read-weak-byref.m
Fixed testcase to reflect call qualifier
llvm-svn: 91640
non-existing 'isa' field of a non-existing struct type
all related to legacy type definition for 'id' which we have
dropped in clang in favor of a built-in type.
(fixes radar 7470820).
llvm-svn: 91455
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
of a subclass (direct or indirect) of a weak_import root class, emit a weak reference
for the root class's metaclass (should complete radar 6815425).
llvm-svn: 90249
type and fixes a long-standing code gen. crash reported in
at least two PRs and a radar. (radar 7405040 and pr5025).
There are couple of remaining issues that I would like for
Ted. and Doug to look at:
Ted, please look at failure in Analysis/MissingDealloc.m.
I have temporarily added an expected-warning to make the
test pass. This tests has a declaration of 'SEL' type which
may not co-exist with the new changes.
Doug, please look at a FIXME in PCHWriter.cpp/PCHReader.cpp.
I think the changes which I have ifdef'ed out are correct. They
need be considered for in a few Indexer/PCH test cases.
llvm-svn: 89561
This fixes some bad -O0 codegen and the unnecessary clearing of al on entry to objc_msgSend for most message sends.
<rdar://problem/7102824> [irgen] unnecessary xorb on calls to objc_msgSend on x86_64
llvm-svn: 82118
- Previously this would crash on recursive types, and it was also incorrectly
stripping off a level of indirection.
- I'm not 100% convinced this is all correct, but it should be a monotonic
improvment.
llvm-svn: 75582
The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.
Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
llvm-svn: 75314
variables in ObjC's Next runtime mode. Next runtime also implicitly applies
'used' attribute on some of its meta-data. This results in two
'llvm.used' arrays to be generated, and one of them is renamed to
'llvm.used1'.
llvm-svn: 74008
___Block_byref_id_object_dispose and ___Block_byref_id_object_copy
functions so that we can simply reuse instead of creating a new one.
Additionally, add an assert to ensure no one yet tries to align a
__block variable beyond the alignment of a pointer as the codegen is
incomplete.
llvm-svn: 72974
- Otherwise we emit internal names with embedded '\01' characters,
which confuses some tools.
- Ideally all the code which wants to get a "display name" for the
given function should follow one code path, but this should be a
monotonic improvement for now.
llvm-svn: 71774
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
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
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
compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
types.
- I broke this in the switch to representing interfaces with opaque
types.
- <rdar://problem/6822660> clang crashes on subscript of interface in
32-bit mode
llvm-svn: 70009
- As with malloc and friends, this is important where the return type
on a 64-bit platform would otherwise end up discarding the upper
32-bits.
llvm-svn: 69874
Rework the shadow struct that is layed out for Objective-C classes.
- Superclasses are now always laid out in their shadow structure at
the first field.
- Prior to this, the entire class heirarchy was flattened into a
single structure which meant that alignment, padding, and bitfields
were incorrect (the ASTRecordLayout was correct however, which
meant our debug info didn't coincide with ivar offsets, for
example).
- This is still very suboptimal (for example, ivar are looked up
recursively, but I believe the ivar layout itself is now at least
close to correct.
- <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
backwards
llvm-svn: 69811
- Superclasses are now always laid out their shadow structure at the
first field.
- Prior to this, the entire class heirarchy was flattened into a
single structure which meant that alignment, padding, and bitfields
weren't packed correctly (the ASTRecordLayout was correct however,
which meant our debug info didn't coincide with ivar offsets, for
example).
- This is still very suboptimal, but I believe the ivar layout itself
is now at least close to correct.
- <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
backwards
llvm-svn: 69771
- The confusing IRgen bitfield interface is partly to blame here;
fixing the functional error for now, cleanups to the interface to
follow.
llvm-svn: 69503
- This was particularly bad since I fixed one instance of this name
and not another, meaning we got an LLVM module with the same
effective name in two different globals!
llvm-svn: 69205
Fariborz Jahanian