[cfe-commits] r147306 - /cfe/trunk/lib/Analysis/CFG.cpp

Xu Zhongxing xu_zhong_xing at 163.com
Tue Jan 3 17:40:05 PST 2012


AST does have all these information in it. It's just the linearized CFG 
reverses the order in which we see the AST nodes.

于 2012/1/4 5:48, Ted Kremenek 写道:
> Interesting.  If the AST doesn't have enough information for the analyzer (and other clients) to do a good job here, then I think it would be reasonable to investigate pushing an AST-level change to fix the issue.
>
> On Dec 29, 2011, at 4:03 AM, Xu Zhongxing wrote:
>
>> I admit this is not a correct solution. If I set add CXXConstructExpr bit in the CFG::BuildOptions to false, there exist some cases CXXConstructExpr is not added as block-level expr, where it should.
>>
>> Linearizing the CFG is great idea. I already enjoy it very much.
>>
>> We need to provide more information to CXXConstructExpr: its destination object (a variable or a temporary object that should be conjured) and its kind (base,complete).
>>
>> For the destination object, we could always conjure a temporary object and use LazyCompoundVal to bind the real object being constructed when we later see it.
>>
>> 于 2011/12/29 13:59, Ted Kremenek 写道:
>>> Hi Zhongxing,
>>>
>>> I don't understand how this is actually fixing (1) or (2).  Can you explain?  We're moving to a place where we will likely linearize the entire CFG (this is already the case for the static analyzer), so it would be great to find a solution to (1) or (2) that doesn't depend on whether or not CXXConstructExpr is a block-level expression.
>>>
>>> Thanks,
>>> Ted
>>>
>>> On Dec 27, 2011, at 8:38 PM, Zhongxing Xu wrote:
>>>
>>>> Author: zhongxingxu
>>>> Date: Tue Dec 27 22:38:46 2011
>>>> New Revision: 147306
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=147306&view=rev
>>>> Log:
>>>> Enable the user to control whether CXXConstructExpr will be added as a
>>>> block-level expr. Currently CXXConstructExpr is always added as a block-level
>>>> expr. This caused two problems for the analyzer (and potentially for the
>>>> CFG-based codegen).
>>>> 1. We have no way to know whether a ctor call is base or complete.
>>>> 2. We have no way to know the destination object being contructed.
>>>>
>>>> Modified:
>>>>    cfe/trunk/lib/Analysis/CFG.cpp
>>>>
>>>> Modified: cfe/trunk/lib/Analysis/CFG.cpp
>>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/CFG.cpp?rev=147306&r1=147305&r2=147306&view=diff
>>>> ==============================================================================
>>>> --- cfe/trunk/lib/Analysis/CFG.cpp (original)
>>>> +++ cfe/trunk/lib/Analysis/CFG.cpp Tue Dec 27 22:38:46 2011
>>>> @@ -2768,7 +2768,7 @@
>>>> CFGBlock *CFGBuilder::VisitCXXConstructExpr(CXXConstructExpr *C,
>>>>                                             AddStmtChoice asc) {
>>>>   autoCreateBlock();
>>>> -  if (!C->isElidable())
>>>> +  if (!C->isElidable()&&   asc.alwaysAdd(*this, C))
>>>>     appendStmt(Block, C);
>>>>
>>>>   return VisitChildren(C);
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>




More information about the cfe-commits mailing list