On Thu, Jul 25, 2013 at 9:50 PM, Jeff Law <l...@redhat.com> wrote: > On 07/25/2013 04:40 PM, Joseph S. Myers wrote: >> >> On Thu, 25 Jul 2013, Marek Polacek wrote: >> >>> So far it sanitizes division-by-zeros, shifts and >>> __builtin_unreachable calls. This is of course far from being >>> complete; I intend to write more features during this 4.9 stage. >> >> >> Such as everything needed for it to replace -ftrapv (for -ftrapv to become >> an alias for an appropriate subset of this option)? > > I'm guessing Marek would probably start with looking to provide feature > parity with LLVM's -fsanitize=undefined which is defined as: > > -fsanitize=undefined: Fast and compatible undefined behavior checker. > Enables the undefined behavior checks that have small runtime cost and no > impact on address space layout or ABI. This includes all of the checks > listed below other than unsigned-integer-overflow.
What does it mean by "unsigned-integer-overflow"? Unsigned integers never overflow. Or maybe I misread the documentation here. Thanks, Andrew Pinski > > So I wouldn't necessarily expect ubsan, at least in the near future, to > catch the -ftrapv stuff. Though it's something that might be able to be > added at some point. > > > >> What happens if you bootstrap with this enabled - do whatever failures >> appear look like genuine bugs? Running the testsuite with a compiler >> built with this option? Running the testsuite with this option used when >> compiling all these tests. I guess that initially a bootstrap with this >> option may fail because of existing bugs, and so the other tests mentioned >> can't yet be run - but using this option on GCC itself, and making sure >> that as far as possible it doesn't break compiling things or change >> diagnostics generated at compile time, seem like good goals. > > Note that the instrumentation happens in c-family/ so we might not be fully > instrumenting what comes out of the C++ front-end. However, if we're > getting a reasonable amount of sanitization, it'd be real interesting to > track down any failures that trigger for bootstraps. > > There are some projects out there that using ubsan (SpiderMonkey for > example) from LLVM to root out issues. > > Jeff > >