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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
