<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 1:31 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ted, Jordan, Anna: ping.<div><br></div><div>This is really important for us - we love the analyzer, but without this patch, we basically cannot use it (apart from maintaining our own private fork, which we would rather not do, if at all possible). Every time somebody follows a code path that leads to an incorrect handling of temporary destructors, we loose a bunch of engineering time - might we be able to get this patch re-applied under a flag?</div>
</div></blockquote><div><br></div><div>I haven't at all looked at the actual patch or the false positives, but a few questions come to mind:<br><br>My understanding is that this helps fix C++ quality, but regresses some ObjC cases, yes?<br>
<br>If so, why don't we only do this when compiling C++ (and, maybe, ObjC++ - I assume it helps more than it hurts there) - in that way we wouldn't regress ObjC quality and wouldn't need a flag?<br><br>What are the specific ObjC regressions? Are they a matter of luck in the current design, or intentional but the design that works for them is inflexible to this enhancement? (this is a difficult question to explain - but I'm kind of drawing an analogy from the LLVM optimization pipeline - sometimes improving one optimization exposes flaws in another, through no fault of the improvement. We still care about the overall regression and work diligently to fix or revert, etc)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888">
<div><br></div><div>/Manuel</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 10:57 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So, given the 50% false positive rate for C++ code I'd be curious what regressions were there in C/Obj-C code that tip the scale towards reverting the patch rather than living with the regressions.<div>

<br>
</div><div>Thanks!</div><span><font color="#888888"><div>/Manuel</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 11:38 AM, Daniel Connelly <span dir="ltr"><<a href="mailto:dconnelly@google.com" target="_blank">dconnelly@google.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>(cc: <a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>, <a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>)</div>


<div><br></div>As a bit of a follow-up, we are still very interested in getting this worked out, as it's a significant barrier to the Analyzer's usefulness. All of our C++ projects make extensive use of custom assertions. For example,<div>



<br></div><div>CHECK(condition) << "something happened with the hydrospanners";</div><div><br></div><div>which logs a message and kills the program if the condition isn't met. None of these custom assertions are pruning code paths due to the missing conditional expression support. For example, when building Chromium, <span style="font-size:13px;font-family:arial,sans-serif">the difference between running without and with the reverted patch is 1982 reported errors vs. 3210 reported errors. This number is a bit conservative, since we also have this problem in dependent libraries that don't (but could) use analyzer_noreturn on their assertions; the real cost is that about 50% of all errors reported by the analyzer are false positives of this form.</span></div>



</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 11:32 AM, Daniel Connelly <span dir="ltr"><<a href="mailto:dconnelly@google.com" target="_blank">dconnelly@google.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">After digging into this for a couple of weeks across the 2013/2014 boundary, I now doubt that my 20% time will be enough to properly implement this support. Anybody who's interested should feel free to work on this instead, as I'll not be moving forward with it. Jordan, thanks for the pointers and the summary of the problem!</div>




<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 1:55 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Dec 16, 2013, at 6:57 , Daniel Connelly <<a href="mailto:dconnelly@google.com" target="_blank">dconnelly@google.com</a>> wrote:</div>




<br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
On Fri, Dec 13, 2013 at 7:13 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>





</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>
<br></div><div>In discussing the first problem, Ted and Anna realized that the liveness information for nested && and || expressions was still incorrect: the outermost expression may potentially depend on all of the inner expressions, but that means that those sub-expressions are <i>always</i> considered live (since expressions are marked dead, in a reverse analysis, at the point of evaluation, and there are paths that don't evaluate a particular sub-expression in a complex logical expression). This wasn't an issue before because && and || didn't actually use those expressions to compute their value, but it's still incorrect.</div>







</div></blockquote><div><br></div><div>Is this <a href="http://llvm.org/bugs/show_bug.cgi?id=18159" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=18159</a> ?</div></div></div></div></div></blockquote><div><br></div>




Yes.</div><div><br></div><div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Thanks for the overview. This is all pretty new to me, so I'm going to dig into the problem for a couple of days and hopefully come up with some intelligent questions.</div>




</div></div></blockquote></div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">Sorry for the blast of information. If you want an easier place to start playing with the analyzer, you could try hacking on productizing SimpleStreamChecker. (And if you haven't watched our talk from last year's LLVM dev meeting, I definitely suggest taking the time to do so. It's aimed at checker writers, but still describes the general structure of the analyzer. It's linked near the top of <a href="http://clang-analyzer.llvm.org/checker_dev_manual.html" target="_blank">http://clang-analyzer.llvm.org/checker_dev_manual.html</a>)</div>




<span><font color="#888888"><div class="gmail_quote"><br></div><div class="gmail_quote">Jordan</div></font></span></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div>
-- <br><div dir="ltr">
<span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Daniel Connelly |</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer <span><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">–</span></span> Chrome |</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:dconnelly@google.com" target="_blank">dconnelly@google.com</a> |</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> </span><span style="font-size:medium;font-family:Times"><br>




</span><br><div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Google Germany GmbH</span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Dienerstr. 12</span></font></div>




<div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">80331 München</span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px"><br></span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Registergericht und -nummer: Hamburg, HRB 86891</span></font></div>




<div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Sitz der Gesellschaft: Hamburg</span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Geschäftsführer: Graham Law, Christine Elizabeth Flores</span></font></div>




</div><div><br></div></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Daniel Connelly |</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer <span><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">–</span></span> Chrome |</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:dconnelly@google.com" target="_blank">dconnelly@google.com</a> |</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:small;line-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> </span><span style="font-size:medium;font-family:Times"><br>



</span><br><div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Google Germany GmbH</span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Dienerstr. 12</span></font></div>



<div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">80331 München</span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px"><br></span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Registergericht und -nummer: Hamburg, HRB 86891</span></font></div>



<div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Sitz der Gesellschaft: Hamburg</span></font></div><div><font color="#555555" face="sans-serif"><span style="line-height:19.5px">Geschäftsführer: Graham Law, Christine Elizabeth Flores</span></font></div>



</div><div><br></div></div>
</div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>