Looks good to me.

On Jan 10, 2012, at 5:42 PM, Xu Zhongxing wrote:

> Hi Ted,
> 
> I would like to add elidable CXXConstructExpr as block-expr. Since expression
> 
> (CXXConstructExpr 0x3268658 <col:5, col:7> 'class A''void (const class A &) 
> throw()' elidable
> 
> converts an lvalue 'const class A &' to an rvalue 'class A'. This step is 
> useful during AST evaluation.
> 
> So is this patch ok?
> 
> Index: lib/Analysis/CFG.cpp
> ===================================================================
> --- lib/Analysis/CFG.cpp    (revision 147306)
> +++ lib/Analysis/CFG.cpp    (working copy)
> @@ -2768,8 +2768,7 @@
> CFGBlock *CFGBuilder::VisitCXXConstructExpr(CXXConstructExpr *C,
>                                             AddStmtChoice asc) {
>   autoCreateBlock();
> -  if (!C->isElidable() && asc.alwaysAdd(*this, C))
> -    appendStmt(Block, C);
> +  appendStmt(Block, C);
> 
>   return VisitChildren(C);
> }
> 
> 于 2012/1/4 9:40, Xu Zhongxing 写道:
>> 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
>>>>>> [email protected]
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>> _______________________________________________
>>>>> cfe-commits mailing list
>>>>> [email protected]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> _______________________________________________
>> cfe-commits mailing list
>> [email protected]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 


_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to