[cfe-dev] Consumed analysis resets its state in between CFG blocks

[Jordan Rose]

Neither of these are part of the analyzer; they're part of the analysis-based warnings in Clang. libClangAnalysis is the common base between the two, which is why we have to be careful about the CFG, but the full analyzer infrastructure isn't going to be the answer.

"A new block may only be started if there is control flow" probably is not enforced, but I'm not sure why we wouldn't do that. ("control flow" doesn't have to mean a C/C++ notion of control flow; it can be something like the static variable DeclStmt that clients of the CFG can use to decide where execution goes next.)

Jordan


On May 5, 2014, at 5:51 , Manuel Klimek <klimek at google.com> wrote:

> Btw, I see a similar problem with the ReachableCode analysis:
> lib/Analysis/ReachableCode.cpp:61 static bool isDeadReturn(...)
> seems to rely on the invariant:
> "A new block may only be started if there is control flow"
> Is the analyzer actually trying to enforce this invariant?
> 
> Thanks!
> /Manuel
> 
> 
> 
> 
> On Sat, May 3, 2014 at 5:38 PM, Manuel Klimek <klimek at google.com> wrote:
> Heya,
> 
> I am currently playing around with how the CFG looks in the face of temporary destructors; one interesting tidbit is that temporary destructors insert CFG blocks in places where one might not have expected them - for example, before the call to an arbitrary destructor at the end of a full expression.
> 
> Now the consumed analysis kills it state unconditionally at the end of each block:
> http://reviews.llvm.org/diffusion/L/browse/cfe/trunk/lib/Analysis/Consumed.cpp;207914$1400
> This leads to missed warnings when we leave a CFG block in the middle of an expression, and in general feels very brittle regarding future changes to the CFG's layout.
> 
> I was wondering whether there are already mechanisms in the CFG to deal with issues like this (I'd have expected a consumed analysis to work on the scope of a variable instead of arbitrary block boundaries - for example, could we use REGISTER_MAP_WITH_PROGRAMSTATE?).
> 
> Thoughts?
> /Manuel
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140505/378777ee/attachment.html>