[cfe-dev] CFG initializers and destructors patch

Marcin Świderski marcin.sfider at gmail.com
Mon Sep 6 22:53:33 PDT 2010


W dniu 7 września 2010 07:22 użytkownik Zhongxing Xu
<xuzhongxing at gmail.com>napisał:

> I implemented a minimum patch that set up the CFGElement hierarchy based on
> Marcin's patch.
>
> I use 2 pointers directly in CFGElement, because this make logic simpler
> and we can optimize it anytime later.
> The first pointer's integer bits are used to mark the main kind of the
> CFGElement. The second are used to mark the kind of dtors.
>
> Scopes are removed since we haven't decided if to include it. Other parts
> are necessary adaption to the new CFGElement interface.
>
> This should be easier to review.
>
> Thanks for doing this, I really appreciate. One thing I would add to this
patch, that won't complicate it but will make code clearer, is a rename in
CFGBlock from StatementList to ElementList and Statements to Elements.

2010/9/7 Zhongxing Xu <xuzhongxing at gmail.com>
>
>
>>
>> 2010/9/7 Marcin Świderski <marcin.sfider at gmail.com>
>>
>> W dniu 6 września 2010 07:49 użytkownik Zhongxing Xu <
>>> xuzhongxing at gmail.com> napisał:
>>>
>>>
>>>>
>>>> 2010/9/6 Marcin Świderski <marcin.sfider at gmail.com>
>>>>
>>>> W dniu 6 września 2010 05:37 użytkownik Zhongxing Xu <
>>>>> xuzhongxing at gmail.com> napisał:
>>>>>
>>>>> Hi Marcin,
>>>>>>
>>>>>> Thank you for working on this. This patch is really big. I suggest we
>>>>>> focus on the 'CFGElement' aspect in the first patch, and put the
>>>>>> 'LocalScope' things in later patches.
>>>>>>
>>>>>> About CFGElement, I think we an avoid using two pointers in it.
>>>>>> Currently the second pointer data is used for 'the statement that triggers
>>>>>> the dtor. I think we don't need a pointer for it. The position where the
>>>>>> CFGElement resides is the place where it is triggered. It is not triggered
>>>>>> by a statement.
>>>>>>
>>>>>> Then for the rest one pointer, we let it point to the VarDecl for
>>>>>> AutomaticObjectDtor, to the initializer for Base and Member dtors, to
>>>>>> CXXBindTemporaryExpr for temporary dtor.
>>>>>>
>>>>>> 2010/9/3 Marcin Świderski <marcin.sfider at gmail.com>
>>>>>>
>>>>>>  Hi
>>>>>>>
>>>>>>> I'm sending a patch with implementation of C++
>>>>>>> - initializers from constructor initialization list,
>>>>>>> - implicit destructors for objects with automatic storage duration.
>>>>>>>
>>>>>>> For destructors I've taken care of:
>>>>>>> - block local scopes,
>>>>>>> - if/switch/for/while/do local scopes (in case there's no block),
>>>>>>> - if/switch/for/while condition variables,
>>>>>>> - catch exception variable,
>>>>>>> - temporaries bound to const reference.
>>>>>>>
>>>>>>> Is there something that I've missed?
>>>>>>>
>>>>>>> As it have been suggested I've created hierarchy of CFGElements.
>>>>>>> Currently there're two unused types for implicit destructor calls in
>>>>>>> destructor. I've did not revert ability of CFGElement to cast/dyn_cast to
>>>>>>> Stmt, because it would lead to situation when cast<Stmt>(SomeCFGElement)
>>>>>>> would return null. I did however add method for downcasting CFGElement
>>>>>>> object to object of its implemntation class (returned by value, not pointer)
>>>>>>> with returning invalid object on invalid cast.
>>>>>>>
>>>>>>> I did not add CFGElement for destructors of temporary objects. After
>>>>>>> giving it some thought I came to a conclusion that it shouldn't be covered
>>>>>>> by CFG, because it clearly needs path-sensitiveness.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Marcin
>>>>>>>
>>>>>>
>>>>>> Should I split it and send it cfe-commits with some comments?
>>>>
>>>>
>>>> Yes, I would like we settle down the CFGElement part first, then the CFG
>>>> construction part.
>>>>
>>> I won't be able to prepare patches before the weekend. I hope it won't be
>>> much of a problem to anyone.
>>>
>>> As I understand each patch should introduce chunk of code that would not
>>> break the compilation?
>>>
>>> Cheers
>>> Marcin
>>>
>>
>> Hi Marcin,
>>
>> I will try to review this one, since splitting this patch may cause much
>> trouble for you.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100907/154a6353/attachment.html>


More information about the cfe-dev mailing list