[LLVMdev] finding integer undefined behaviors using clang

Nick Lewycky nicholas at mxc.ca
Sun Apr 10 23:30:54 PDT 2011

John Regehr wrote:
> Hi Cameron,
> I agree, it would be nice to integrate this.  My quick analysis of the
> situation, however, was that there's probably some difference of opinion
> about how heavyweight the trap handler should be.  Ours is very heavy, in
> order to produce informative messages.  People using traps in production
> code -- for example to simulate infinitely-ranged integers -- aren't going
> to like this.  It's probably possible to engineer a solution that makes
> everyone happy, but it may be quite a bit of work.
> In the meantime I wanted to get our code out there so people can use it.
> My hope is that if it turns out to be valuable, someone more conversant
> with LLVM will figure out how it fits into the bigger picture.

Yes, I want to use this and would like to see it land in clang upstream.

I don't think you need the llvm patch. That allows us to mark the 
llvm::Functions as having the 'nointegercheck' attribute applied to 
them, but it looks like that's never used, only the 
clang::NoIntegerCheckAttr is needed. Any reason to keep the llvm 
attribute around?

Then the trap handler looks simple enough that it could go into clang's 
lib/runtime. It's not clear to me what to do about the hashtable and 
mersenne twister; things in lib/runtime should provide a C interface but 
I think we can write it in C++ and make use of C++ and LLVM's existing 
facilities. Then clang should statically link the programs against the 
trap handler when the catch-undefined-... flags are provided.

I'm not worried about making a light-weight trap handler replacement 
just yet because I see this as a testing tool that doesn't go into 
production binaries. Creating one that does seems to be a separate 
problem to me.

Is there a repository with this code that I can hack on? Or what should 
I do from here?


More information about the llvm-dev mailing list