[cfe-dev] [RFC] Extending and improving Clang's undefined behavior checking

[Richard Smith]

On Mon, Aug 13, 2012 at 10:53 AM, John Regehr <regehr at cs.utah.edu> wrote:

> Regehr et al's IOC has code to handle a few of these checks already, which
>> should be
>
> straightforward to apply to Clang trunk (assuming the IOC guys are still
>> happy with
>> that?). Low overhead would be an explicit goal of all of these checks.
>>
>
> 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?
>
> Richard, if you're willing to help us get this into the trunk we'd be
> super happy.


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.


> IOC is in some ways quite ambitious here, and provides options to not only
>> diagnose a
>
> problem, but also to call a function which can produce a value for the
>> operation and
>> recover. I'm not proposing adding such a feature to Clang at this time
>> (I'll leave that
>> to the IOC folks).
>>
>
> IOC is fairly modular in the sense that the checking logic doesn't care
> that much about the trap handling logic.
>
> 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.
>

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.


> 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.


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.


>  * -fchecks-num. This provides logging output when checks are inserted,
>> and would not be
>
> valuable to my target audience.
>>
>
> You mean to always terminate the program on undefined behavior?


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.


> 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.


With the current proposal, there are two ways to mitigate this problem:
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.
2) The -fcatch-undefined-behavior=... options will allow individual checks
to be disabled, where they are blocking the user from finding other issues.

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.

Thanks!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120813/b58dcc50/attachment.html>