[cfe-commits] r104281 - in /cfe/trunk: lib/CodeGen/CGExprCXX.cpp test/CodeGenObjC/objc-gc-aggr-assign.m

Douglas Gregor dgregor at apple.com
Thu May 20 15:33:07 PDT 2010


On May 20, 2010, at 3:12 PM, Fariborz Jahanian wrote:

> 
> On May 20, 2010, at 2:44 PM, Douglas Gregor wrote:
> 
>> 
>> On May 20, 2010, at 2:38 PM, Fariborz Jahanian wrote:
>> 
>>> Author: fjahanian
>>> Date: Thu May 20 16:38:57 2010
>>> New Revision: 104281
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=104281&view=rev
>>> Log:
>>> Adds support for generation of objc_memmove_collectable API
>>> in Objective-C++ mode.
>> 
>> Should EmitAggregateCopy have this functionality internally, rather than teaching all its callers to generate the different APIs?
> 
> objc_memmove_collectable is a write-barrier and is to be generated for assignments only. I initially looked at call sites for EmitAggregateCopy and
> it is called in many other cases where a copy is needed. So, I did not put it there.

Ah, I didn't think about that. Thanks for the clarification!

>> 
>> 
>> Also, it looks like the HasObjectMember bit isn't propagated from base classes to derived classes, e.g.,
>> 
>> struct Base {
>>   NSObject *object;
>> };
>> 
>> struct Derived : Base { }; // won't have HasObjectMember bit set?
> 
> This is a valid point. g++ does not do this; neither does clang. I will bring it up with the group.
> It is probably harmless to add.


Personally, I view this as a g++ and clang++ bug: there's clearly a pointer to an Objective-C object in that memory, so we should be telling the runtime about it. Let's fix it in Clang.

	- Doug



More information about the cfe-commits mailing list