r209908 - Start adding support for dllimport/dllexport on classes (PR11170)

[Alp Toker]

On 30/05/2014 23:03, Hans Wennborg wrote:
> On Fri, May 30, 2014 at 12:28 PM, Alp Toker <alp at nuanti.com> wrote:
>> On 30/05/2014 19:59, Hans Wennborg wrote:
>>> --- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
>>> +++ cfe/trunk/lib/CodeGen/CGClass.cpp Fri May 30 11:59:42 2014
>>> @@ -1425,8 +1425,8 @@ namespace {
>>>    /// in reverse order of their construction.
>>>    void CodeGenFunction::EnterDtorCleanups(const CXXDestructorDecl *DD,
>>>                                            CXXDtorType DtorType) {
>>> -  assert(!DD->isTrivial() &&
>>> -         "Should not emit dtor epilogue for trivial dtor!");
>>> +  assert((!DD->isTrivial() || DD->hasAttr<DLLExportAttr>()) &&
>>> +         "Should not emit dtor epilogue for non-exported trivial dtor!");
>>
>> Instead of changing all these isTrivial() checks, did you consider making
>> special members under the DllExport attribute non-trivial e.g. from within
>> SpecialMemberIsTrivial()?
>>
>> Seems to work and have more consistent semantics if that's what we're going
>> for.
> I agree that changing the two isTrivial() checks to handle the
> dllexport attribute is a little annoying, but I don't think it's too
> bad. I don't particularly like the idea of changing
> SpecialMemberIsTrivial(). I certainly still think of these functions
> as trivial even if they have the attribute on them. The attribute just
> makes us need to emit them.

Good explanation, looking over it again things seem fine and I agree 
there isn't really a worthwhile way to encapsulate it.

Idle thought: I wonder if anything else would benefit from emission of 
trivial members. It sounds like the facility may be vaguely useful for 
other kinds of ABI hackery attributes.

Alp.

-- 
http://www.nuanti.com
the browser experts