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

[John Regehr]

> There are three different (and mostly orthogonal, design-wise) areas where I would like
> to make improvements to Clang's undefined behavior checking:

This is all great and will be a huge benefit to Clang users.

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

> IOC also adds:
>   -fcatch-undefined-ansic-behavior
>   -fcatch-undefined-c99-behavior
>   -fcatch-undefined-cxx0x-behavior
>   -fcatch-undefined-cxx98-behavior
>   -fcatch-undefined-nonarith-behavior

We are currently revising the command line interface to IOC.  We very much 
want it to fit into the bigger undefined behavior checker picture.

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

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.

> test.cc:4:12: runtime error: left shift count 33 >= width of type 'int' (32 bits)
>   return i << n;
>            ^  ~
>               33
> test.cc:7:30: note: in call to 'f' here
> Illegal instruction

This is a good level of verbosity, I think.

>  * -fuse-intrinsic. This allows the choice of whether to use LLVM's overflow intrinsics.
> I intend to use such intrinsics unconditionally.

Yes, good, though I'll note that last time we measured, the intrinsics 
were not uniformly a performance win over protecting maybe-undefined 
operations using explicit checks.  As far as we could tell, this is 
because an insufficient number of LLVM passes know what to do with the 
overflow intrinsics. Chris encouraged us to file bugs but it's very hard 
to track down these missed optimizations.

>  * -fuse-random-value. This allows recovery from detected undefined behavior by providing
> a value for the operation, which is not part of my proposal.

Good.

>  * -fhandler-null. This selects the usage of an alternate runtime library.

Good.

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

>  * -fcatch-non-ubc-type. This is designed to catch unsigned integer overflow, and some
> other cases which don't have undefined behavior, and so is not directly connected to this
> work.

We like these checks but it is totally reasonable to not put them in at 
first. Once the rest of the infrastructure is in the trunk, it should be 
easy for us to push this in separetely.

Thanks again.

John