[cfe-commits] r118991 - in /cfe/trunk: lib/Analysis/CFG.cpp test/Analysis/temp-obj-dtors-cfg-output.cpp

Marcin Świderski marcin.sfider at gmail.com
Sat Nov 13 16:16:58 PST 2010


W dniu 14 listopada 2010 00:48 użytkownik Zhongxing Xu <
xuzhongxing at gmail.com> napisał:

>
>
> 2010/11/14 Marcin Świderski <marcin.sfider at gmail.com>
>
> W dniu 13 listopada 2010 12:37 użytkownik Zhongxing Xu <
>> xuzhongxing at gmail.com> napisał:
>>
>> I see some unbalancing before this patch. (See the test case that was
>>> modified.) Could you provide an example that is unbalanced by this patch?
>>>
>>> 2010/11/13 Marcin Świderski <marcin.sfider at gmail.com>
>>>
>>> Hi Zhongxing
>>>>
>>>> Won't it lead to unbalancing ctors/dtors like I've written in discusion
>>>> after commit r118159?
>>>>
>>>>
>>>> When I wrote about unbalancing I meant that removing elidable
>> CXXConstructExpr and then removing destructors for temporaries that where
>> created with those expressions will unbalance ctors/dtors calls. Because not
>> every call to the ctor is a block level statement this is not visualised in
>> the CFG.
>>
>> Example of this is simple:
>>
>> class A {
>> public:
>>   A() {}
>>   ~A() {}
>> };
>>
>> A foo() { return A(); }
>>
>>  AST for function foo() looks like this:
>>
>> A foo() (CompoundStmt 0x105048b98 <main.cpp:7:9, col:23>
>>   (ReturnStmt 0x105048b70 <col:11, col:20>
>>     (CXXExprWithTemporaries 0x105048b38 <col:18, col:20> 'class A'
>>       (CXXTemporary 0x105048a80)
>>       (CXXConstructExpr 0x105048af0 <col:18, col:20> 'class A''void (const
>> class A &) throw()' elidable
>>         (ImplicitCastExpr 0x105048ad0 <col:18, col:20> 'const class A'
>> <NoOp>
>>           (CXXBindTemporaryExpr 0x105048a88 <col:18, col:20> 'class A'
>> (CXXTemporary 0x105048a80)
>>             (CXXTemporaryObjectExpr 0x105048a38 <col:18, col:20> 'class
>> A''void (void)')))))))
>>
>> If we want to ensure that the CFG is constructed from AST with all
>> elidable constructors elided, for above example we would have to ignore
>> both CXXConstructExpr and CXXBindTemporaryExpr. In your implementation only
>> the first will be elided.
>>
>
> Hi Marcin,
>
> I still do not understand your point. The current implementation works well
> for the above example. One block-level expr for CXXTemporaryObjectExpr. One
> temporary dtor for CXXBindTemporaryExpr.
>

If CXXConstructExpr that constructs the return value will be elided, object
created with CXXTemporaryObjectExpr
will be the return value and should not be destroyed. So eliding copy
constructor should also prevent destroying
temporary from which it would copy, not the other way around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20101114/d8d28e46/attachment.html>


More information about the cfe-commits mailing list