<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 5, 2014 at 6:49 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div>
</div></blockquote><div><br></div><div>What would be "full analyzer infrastructure" here? The <span style="font-size:13px;font-family:arial,sans-serif">REGISTER_MAP_WITH_</span><span style="font-size:13px;font-family:arial,sans-serif">PROGRAMSTATE part?</span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>"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.)</div>
</div></blockquote><div><br></div><div>I'm aware control flow doesn't necessarily mean C/C++ control flow.</div><div>Here's my reasons why we might not want to have that invariant.</div><div>1. if I remember correctly I have already seen blocks that don't have terminators that just flow into a single other block (I'll try to fish one out if you're curious); so I was surprised to see other places basically assert in a comment that this is an assumed invariant</div>
<div>2. it seems that sometimes having the CFG be more uniform regarding different related patterns might be nice (although I see that it is a very very weak argument)</div><div>3. it might just be too hard to assert the invariant, in which case I'd say it's better to explicitly say it's *not* an invariant than to let checks or cfg-based compiler checks rely on it</div>
<div><br></div><div>Thoughts?</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><span class=""><font color="#888888"><div><br></div><div>Jordan</div></font></span><div><div class="h5"><div><br></div><br><div><div>On May 5, 2014, at 5:51 , Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Btw, I see a similar problem with the ReachableCode analysis:<div>lib/Analysis/ReachableCode.cpp:61 static bool isDeadReturn(...)</div><div>seems to rely on the invariant:</div><div>
"A new block may only be started if there is control flow"</div>
<div>Is the analyzer actually trying to enforce this invariant?</div><div><br></div><div>Thanks!</div><div>/Manuel</div><div><br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 3, 2014 at 5:38 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Heya,<div><br></div><div>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.</div>


<div><br></div><div>Now the consumed analysis kills it state unconditionally at the end of each block:</div><div><a href="http://reviews.llvm.org/diffusion/L/browse/cfe/trunk/lib/Analysis/Consumed.cpp;207914$1400" target="_blank">http://reviews.llvm.org/diffusion/L/browse/cfe/trunk/lib/Analysis/Consumed.cpp;207914$1400</a><br>


</div><div>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.</div><div><br></div><div>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?).</div>


<div><br></div><div>Thoughts?</div><span><font color="#888888"><div>/Manuel</div><div><br></div></font></span></div>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div>