summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenObjC
Commit message (Collapse)AuthorAgeFilesLines
...
* Update debug info generation for ObjCObjectPointer changes.Daniel Dunbar2009-07-141-0/+8
| | | | | | | | | - 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
* I just revertd llvm patch. Devang Patel2009-07-141-0/+1
| | | | | | XFAIL this for now until I prepare clang specific patch. llvm-svn: 75575
* New testcase for rev 75503.Devang Patel2009-07-131-0/+18
| | | | llvm-svn: 75504
* Update debug info type cache after fwd decl is replaced by real decl.Devang Patel2009-07-131-0/+19
| | | | llvm-svn: 75473
* Force NeXT runtime for this test.Daniel Dunbar2009-07-111-1/+1
| | | | llvm-svn: 75400
* Fix type conversion of ObjCObjectPointerType.Daniel Dunbar2009-07-111-0/+50
| | | | | | | - Previous code was based on a misunderstanding (on my part) of the type representation. llvm-svn: 75385
* Generate correct prototype for objc_enumerationMutation.Daniel Dunbar2009-07-111-0/+44
| | | | | | - This was a latent bug exposed by the recent objc type changes. llvm-svn: 75383
* This patch includes a conceptually simple, but very intrusive/pervasive change. Steve Naroff2009-07-102-5/+5
| | | | | | | | | | | | 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
* Patch adds test to my previous patch for assigning toFariborz Jahanian2009-07-081-0/+42
| | | | | | | gc'able structs in the Next runtime and adds missing PCH info. llvm-svn: 75014
* Patch fixes an obscure bug when 'used' attribute is applied toFariborz Jahanian2009-06-231-0/+9
| | | | | | | | | 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
* Test modification.Fariborz Jahanian2009-06-141-3/+3
| | | | | | Patch by Jean-Daniel Dupas llvm-svn: 73343
* Don't include system headers when overriding triple.Daniel Dunbar2009-06-131-4/+2
| | | | llvm-svn: 73301
* Force Obj-C runtime version for this testDaniel Dunbar2009-06-131-2/+2
| | | | llvm-svn: 73300
* Support complex properties, ivars and message expressions.Daniel Dunbar2009-06-101-0/+63
| | | | llvm-svn: 73158
* As an optimization, we maintain a cache of generatedMike Stump2009-06-051-0/+15
| | | | | | | | | | ___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
* Place the GC attribute on the same relative pointerFariborz Jahanian2009-06-031-0/+22
| | | | | | | position to make it consistant and to match gcc's behavior, by placing it at the inner-most pointer. llvm-svn: 72784
* A corner case of objc2 gc's write-barrier generationFariborz Jahanian2009-06-011-1/+7
| | | | | | for the Next runtime. llvm-svn: 72703
* Fixed a test case which I am to blame for making itFariborz Jahanian2009-06-011-4/+4
| | | | | | not runaable. llvm-svn: 72695
* No write-barrier for initializations.Fariborz Jahanian2009-05-271-0/+18
| | | | llvm-svn: 72492
* Test for David Chisnall's -fobjc-sender-dependent-dispatch patch.Fariborz Jahanian2009-05-231-1/+7
| | | | llvm-svn: 72330
* Initialize Obj-C GC attributes when emitting BlockDeclRefExprs.Daniel Dunbar2009-05-231-0/+11
| | | | | | - Otherwise we may incorrectly miss generation of some write barriers. llvm-svn: 72313
* Debug info: Initialize runtime language field correctly for Objective-CDaniel Dunbar2009-05-181-1/+9
| | | | | | interface types. llvm-svn: 72036
* Improve test case a wee bitDaniel Dunbar2009-05-181-0/+3
| | | | llvm-svn: 72014
* Classes with "+load" methods need to go in the non-lazy class list (orDaniel Dunbar2009-05-151-0/+30
| | | | | | else the method will not be found by the runtime at class load time). llvm-svn: 71904
* Skip the asm prefix when storing the name in block info.Daniel Dunbar2009-05-141-1/+10
| | | | | | | | | | | - 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
* We need to specify the "linkage name" to the subprogram now that weDaniel Dunbar2009-05-141-1/+4
| | | | | | | emit the correct "display name". I suspect we need more work here, see FIXME for example. llvm-svn: 71761
* Make sure not to include the LLVM asm prefix in function names forDaniel Dunbar2009-05-131-0/+7
| | | | | | debug info. llvm-svn: 71736
* Patch to implement ivar synthesis of properties declared in protocolsFariborz Jahanian2009-05-121-0/+33
| | | | | | only and used in class imllementations (objc2 Nonfragile ABI specific). llvm-svn: 71571
* Patch to allow Nonfragile ABI to use 32-bit style legacyFariborz Jahanian2009-05-111-5/+2
| | | | | | | | 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
* Remove -fobjc-tight-layout, seems to work!Daniel Dunbar2009-05-071-1/+1
| | | | llvm-svn: 71184
* Fixes a bug for objc2's gc in the presense of type-casts.Fariborz Jahanian2009-05-051-0/+21
| | | | llvm-svn: 71041
* Provide basic support for generation of objc2's Fariborz Jahanian2009-05-041-0/+8
| | | | | | | objc_assign_global API when assigning to global objective-c object pointer. llvm-svn: 70939
* Fix the field count in interface record layout (it was incorrectlyDaniel Dunbar2009-05-041-5/+50
| | | | | | | | | | | | 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
* Adding more test to ivar-layout-64.m.Fariborz Jahanian2009-05-041-0/+23
| | | | llvm-svn: 70918
* Compute interface instanceStart and instanceSize using the recordDaniel Dunbar2009-05-041-0/+23
| | | | | | | | | layout. - This is much simpler / more efficient. - This also properly computes the size in the presence of bit-fields. llvm-svn: 70916
* Don't allow clients to traverse into superclass synthesized propertiesDaniel Dunbar2009-05-041-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use the implementation decl for looking up offset while building theDaniel Dunbar2009-05-031-0/+45
| | | | | | | ivar layout. - The layout needs access to synthesized ivars. llvm-svn: 70798
* Rename test caseDaniel Dunbar2009-05-031-0/+0
| | | | llvm-svn: 70797
* API for message dispatch of methods returning floatsFariborz Jahanian2009-04-301-0/+31
| | | | | | to match gcc's closely. llvm-svn: 70493
* only support int128_t on 64-bit and larger targets. 32-bit targets don'tChris Lattner2009-04-301-1/+1
| | | | | | have support for __divti3 and friends. llvm-svn: 70480
* initial support for __[u]int128_t, which should be basicallyChris Lattner2009-04-301-1/+6
| | | | | | | | 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
* Export lazy references of .objc_class_name of class namesFariborz Jahanian2009-04-291-0/+6
| | | | | | | referenced in a category implementation meta-data (Next objc 32bit abi). llvm-svn: 70407
* rdar://6827200 - [sema] reject statically allocated arrays of interface typesChris Lattner2009-04-271-3/+3
| | | | | | | Upgrade "array of interface" warning to an error. In addition to being a terrible idea, this crashes codegen. llvm-svn: 70178
* Fix pointer addressing and array subscripting of Objective-C interfaceDaniel Dunbar2009-04-251-0/+34
| | | | | | | | | | | 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
* Add a test case for a somewhat obscure scenario.Daniel Dunbar2009-04-241-1/+18
| | | | llvm-svn: 69947
* Add implicit definition of objc_msgSend.Daniel Dunbar2009-04-231-0/+7
| | | | | | | | - 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
* Reapply r69771, with updates & fixes:Daniel Dunbar2009-04-221-0/+56
| | | | | | | | | | | | | | | | | | | | | | 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
* Make sure this test runs on all 3 Objective-C implementations.Daniel Dunbar2009-04-221-1/+3
| | | | llvm-svn: 69786
* Revert r69771, I missed some (obvious) details. :/Daniel Dunbar2009-04-221-56/+0
| | | | llvm-svn: 69773
* Rework the shadow struct that is layed out for Objective-C classes.Daniel Dunbar2009-04-221-0/+56
| | | | | | | | | | | | | | | | | | | - 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
OpenPOWER on IntegriCloud