[cfe-commits] [PATCH] Additional output for AnalyzerStatsChecker

[Anna Zaks]

On Feb 23, 2012, at 1:50 PM, Tom Care wrote:

> The reason I added a Stmt* was because the LocationContext of the node (which starts out as a PostStmt) can be overwritten to become a BlockEdge. The Stmt* pointer is lost in that case, and it becomes difficult to guess where the original Stmt was. Since we only add aborted blocks/nodes when a Stmt was unsupported, I thought that it was important to keep the original pointer to find out why we stopped.
> 

Tom, you must be talking about ProgramPoint/Location, not LocationContext, correct? Can you investigate where it gets overwritten? As far as I understand, it should never change, in fact, it's declared as const. We are only adding predecessors and successors to the ExplodedNodes; they should stay unchanged otherwise.

class ExplodedNode : public llvm::FoldingSetNode {
....
  /// Location - The program location (within a function body) associated
  ///  with this node.
  const ProgramPoint Location;

> Example of the new output:
> 
> /Users/tcare/Projects/llvm/tools/clang/lib/Sema/SemaDeclAttr.cpp:218:5: warning: The analyzer stopped at this point due to an unsupported statement of type CXXBindTemporaryExpr
>    S.Diag(Attr.getLoc(), diag::err_attribute_too_few_arguments) << Num;
>    ^
> 
> /Users/tcare/Projects/llvm/tools/clang/lib/Sema/SemaDeclAttr.cpp:308:28: warning: The analyzer stopped because this block was visited too many times
>  for(unsigned Idx = Sidx; Idx < Attr.getNumArgs(); ++Idx) {
>                           ^
> 
> /Users/tcare/Projects/llvm/tools/clang/lib/Sema/SemaDeclAttr.cpp:934:11: warning: The analyzer stoppedat this point due to visitation limits
>      if (T->isAnyPointerType() || T->isBlockPointerType())
>          ^
> 
> (need to add a space in the last one)
> 
> I'm testing over all of LLVM/Clang right now as I am collecting data.
> 
> Tom
> 
> On 23/02/2012, at 6:04 PM, Anna Zaks wrote:
> 
>> On Feb 23, 2012, at 7:27 AM, Ted Kremenek wrote:
>> 
>>> Looks good to me.  Do you have an example of the new output?
>>> 
>>> On Feb 23, 2012, at 7:08 AM, Tom Care <tom.care at uqconnect.edu.au> wrote:
>>> 
>>>> I made some changes to AnalyzerStatsChecker to make it a bit more useful. Changelog:
>>>> 
>>>> Improved the information output by AnalyzerStatsChecker. In addition to the analysis stats for Decls, AnalyzerStatsChecker now also outputs:
>>>> - Exhausted blocks and sinks, including their approximate location
>>>> - Aborted blocks and their statement locations
>>>> - When and where the analyzer reaches the max block limit
>>>> Some supporting infrastructure changes:
>>>> - CoreEngine now stores Stmt* with the ExplodedNode* in the aborted block data, since the node can change between generation and VisitEndAnalysis
>> 
>> My understanding is that, here, we add a bit of overhead on every analyzes run to make stats more precise. 
>> Could you elaborate/investigate a bit more on why it is absolutely necessary in this case? Is the ExplodedNode you are storing here deleted by the time you reach VisitEndAnalysis? (How is the node changed?)
>> 
>>>> - Exposed 'block limit exceeded' tag to allow AnalyzerStatsChecker to detect a sink caused by exceeding the max visits for a block
>>>> 
>>>> Regarding test cases, any test case made for this checker would break quite frequently as the analyzer is changed. I can't think of a good way to solve this.
>>>> 
>> 
>> Would be great if you could (manually) test this with -analyzer-inline-call.
>> 
>>>> Been a while since my last commit, so a review is much appreciated :)
>>>> 
>>>> Tom
>>>> <AnalyzerStatsChecker.patch>_______________________________________________
>>>> 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
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120223/3ae8f9a2/attachment.html>