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

[John Regehr]

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

Absolutely.  This was one of the IOC design points too.  It makes a big 
difference in usability (though most people don't dislike interactive 
debuggers as much as I do...).

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

Sounds good, though I'm not sure that there will be a measurable penalty 
from recovery.  Either way the code is basically this:

(result, overflow) = op input1, input2
if (overflow) call handler
use result

The dominating effect is whether the overflow can be shown to never 
happen.  If you can't do that, I don't see how the extra branch back from 
the handler matters.  I could be wrong of course.

Anyway, I'm not arguing for executing past the handler in the short term.

If you're the one doing the work, it's your call anyway!

> No, I mean logging at IR generation time indicating how many checks it has
> inserted.

Got it.  Yes, this is useless in general-- we had some esoteric reason for 
it.

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

Sure.  It'll be interesting to see how this goes.  It's even possible that 
taking a harder line on stuff like signed overflows will cause people to 
take them more seriously (as opposed to just ignoring log messages).

John