[cfe-dev] checking for virtual members

John Thompson john.thompson.jtsoftware at gmail.com
Tue Nov 2 16:17:27 PDT 2010


I have no idea.  Bascially, I just need something that tells me that there
won't be any other stuff in the actual object, since vecreturn wants to
return the object in a vector register.  Could you tell me which functions
or function I should call?

Thanks.

-John
On Tue, Nov 2, 2010 at 1:28 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
>  On Nov 2, 2010, at 12:04 PM, John Thompson wrote:
>
>  >Why? Is this what GCC does?
>
> Yes.  The class example I enclosed previously will build with our gcc,
> whereas Clang would not, as Clang only allows a strict POD class or struct
> in the original code.  I just posted a patch on cfe-commits to fix this.
>
>
> Okay. This patch uses isDynamicClass(), which means that we still permit
> classes that involve multiple inheritance. Is that intended? Does it make
> sense?
>
> It seems to me that the right language idea might be the C++0x
> standard-layout class, rather than the idea of a non-dynamic class.
> - Doug
>
>  -John
>
> On Tue, Nov 2, 2010 at 11:54 AM, Douglas Gregor <dgregor at apple.com> wrote:
>
>>
>> On Nov 1, 2010, at 5:05 PM, John Thompson wrote:
>>
>> > I need a way easily check to make sure a function has no virtual
>> functions, or other stuff that would inject extra stuff into an object or
>> structure, as part of the validation for the vecreturn attribute.  How do I
>> do it?
>> >
>> > Checking the CXXRecordDecl::PlainOldData flag with isPOD doesn't work,
>> because the the strict definition of POD goes too far for this case.
>>
>> Why? Is this what GCC does?
>>
>>        - Doug
>
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101102/9ace2f28/attachment.html>


More information about the cfe-dev mailing list