<div class="gmail_quote">On Mon, Aug 13, 2012 at 10:53 AM, John Regehr <span dir="ltr"><<a href="mailto:regehr@cs.utah.edu" target="_blank">regehr@cs.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regehr et al's IOC has code to handle a few of these checks already, which should be</blockquote></div>
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
straightforward to apply to Clang trunk (assuming the IOC guys are still happy with<br>
that?). Low overhead would be an explicit goal of all of these checks.<br>
</blockquote>
<br></div>
Will Dietz, a grad student working with Vikram, is currently hacking IOC into shape for inclusion.  Will, can you make sure Richard has access to our github?<br>
<br>
Richard, if you're willing to help us get this into the trunk we'd be super happy.</blockquote><div><br></div><div>Absolutely. Assuming no-one objects to the direction, I'd be more than happy to provide patch review and other assistance to get the relevant pieces of IOC committed.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IOC is in some ways quite ambitious here, and provides options to not only diagnose a</blockquote></div><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
problem, but also to call a function which can produce a value for the operation and<br>
recover. I'm not proposing adding such a feature to Clang at this time (I'll leave that<br>
to the IOC folks).<br>
</blockquote>
<br></div>
IOC is fairly modular in the sense that the checking logic doesn't care that much about the trap handling logic.<br>
<br>
Our experience with integer overflow checking is that it is totally useless without verbose diagnostics because nobody (including us) can understand what is going on given just a line number.<br></blockquote><div><br></div>
<div>This was what I expected, but it's great that you have evidence to back up my intuition. Ideally, I'd like for most reported issues to be understandable and fixable without any need to descend into a debugger.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The logic for recovering could be very handy, for example to implement AIR integers.  But our priority is to just get the basic checking + trap handling added.</blockquote><div><br></div><div>Great. My concern here is primarily performance: adding the ability to resume after a failure is very likely to restrict the optimizations that can be performed on the generated IR. Adding recovery seems like a fine idea to me so long as it's optional.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * -fchecks-num. This provides logging output when checks are inserted, and would not be</blockquote></div></blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
valuable to my target audience.<br>
</blockquote>
<br></div>
You mean to always terminate the program on undefined behavior?</blockquote><div><br></div><div>No, I mean logging at IR generation time indicating how many checks it has inserted. But I was also intending to always terminate the program on caught undefined behavior.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is probably reasonable as long as you are aware that basically zero C/C++ programs will actually finish normally when you turn this on. Many developers will be so annoyed by this that they will simply not use the checker.</blockquote>
<div><br></div><div>With the current proposal, there are two ways to mitigate this problem:</div><div>1) A goal of this work (which I think I forgot to state explicitly) is ABI compatibility, so it will be possible to build a subset of TUs with -fcatch-undefined-behavior to exclude problematic (possibly third-party) code.</div>
<div>2) The -fcatch-undefined-behavior=... options will allow individual checks to be disabled, where they are blocking the user from finding other issues.</div><div><br></div><div>As I mentioned above, I'm concerned about possible performance implications for the non-failing codepaths from allowing the program to resume after the checks. However, I don't have concrete evidence to support this worry, and it would certainly seem wise to measure the impact of allowing resumption, and make the decision on that basis.</div>
<div><br></div><div>Thanks!</div><div>Richard</div></div>