John Regehr
2011-Apr-09 04:10 UTC
[LLVMdev] finding integer undefined behaviors using clang
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. John
Nick Lewycky
2011-Apr-11 06:30 UTC
[LLVMdev] finding integer undefined behaviors using clang
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? Nick
John Regehr
2011-Apr-12 19:45 UTC
[LLVMdev] finding integer undefined behaviors using clang
Thanks Nick-- this all sounds great!> it looks like that's never used, only the clang::NoIntegerCheckAttr is > needed. Any reason to keep the llvm attribute around?I doubt it, but will double check with Peng.> Is there a repository with this code that I can hack on? Or what should I do > from here?I'm not sure what's the best way to open up this patch for hacking, but am open to suggestions. John
Seemingly Similar Threads
- [LLVMdev] finding integer undefined behaviors using clang
- Initialising Mersenne-Twister with one integer
- [LLVMdev] finding integer undefined behaviors using clang
- predictable bit patterns in runif(n) shortly after set.seed
- A bug in the R Mersenne Twister (RNG) code?