<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 1, 2014 at 6:55 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 class=""><br>
On Apr 30, 2014, at 6:10 , Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
<br>
> I have two more question about how the static analyzer works:<br>
><br>
> 1. how are evaluated conditions cached / invalidated?<br>
> If I have a block<br>
> [B42]<br>
> ...<br>
> T: if [B23.8]<br>
><br>
> From reading processBranch, it looks like the correctness of the analysis of the terminator here relies on the result of B23.8 being available as an SVal if it was fully known at B23.8. If the result of this evaluation is guaranteed to be cached in the state, I'm not sure why doing the same for temporary destructor edges wouldn't work (apart from that it would be harder to implement, as we'd need to make sure the ResolveCondition returns the same part of the condition from the temp dtor terminator as for the terminator condition of the branch that created it, which is something we currently don't model).<br>

> If it's not guaranteed to be cached, I think we'd have a different problem, because the way temporary destructors are introduced when inside and if (condition && temp()), the evaluation of the condition && temp() part gets moved a few blocks away from the terminator that decides which if-branch to take. I have not been able to come up with an example that's problematic, though.<br>

<br>
</div>I said this in the other e-mail, but an expression's value is intended to be live from the time it is computed to the time it is consumed. We also don't really have things set up for expressions to be consumed more than once.<br>

<br>
"Caching" really is the wrong word. The Environment stores everything that has been evaluated until the liveness analysis says it is no longer needed.<br>
<div class=""><br>
<br>
><br>
> 2. how does inlining work, and what are the actual invariants of what has the be inside the same block<br>
> Take the following from the dtor.cpp test:<br>
> struct CheckCustomDestructor {<br>
>   bool bool_;<br>
>   CheckCustomDestructor():bool_(true) {}<br>
>   ~CheckCustomDestructor();<br>
>   operator bool() const { return bool_; }<br>
> };<br>
> bool testUnnamedCustomDestructor() {<br>
>   if (CheckCustomDestructor c = CheckCustomDestructor())<br>
>     return true;<br>
>   return false;<br>
> }<br>
><br>
> This is a regression test for a "return of garbage" warning from the bool operator. I tried to change the CFG in VisitExprWithCleanup to always insert a new block before the temporary dtor decision blocks (as that way the CFG looks more uniform regarding how terminator edges are handled). Funnily enough this breaks the above test (and a few other ones in similarly strange ways). The only difference in the CFG I see is that the last block is split into two blocks, just before the call to the temporary destructor. I have no idea why that would ever affect the copied bool inside 'c', which we later get warned on. In general, it seems like I don't have a good understanding of when putting two statements in different blocks will change how the analyzer sees them.<br>

<br>
</div>Inlining essentially jumps to a different CFG's entry block, and then jumps back when the function is different, with some fix-up before and after. It doesn't affect liveness at all. I wouldn't think that the change you describe would actually affect anything here, but the "garbage collection" that cleans up the Environment, Store, and ConstraintManager does run when entering a new CFG block, among other times. ("On exit from a function", and the conditions listed in shouldRemoveDeadBindings in ExprEngine.cpp.)<br>

</blockquote></div><br></div><div class="gmail_extra">Btw, I think this was a red herring and I discovered the bug to be an ordering problem of the "assignment" statement and the temp dtor statement in the CFG. Apparently the order doesn't matter as long as we're in the same block, but starts to matter when we jump blocks in between.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">See <a href="http://reviews.llvm.org/D3603">http://reviews.llvm.org/D3603</a> for an attempted fix.</div></div>