This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request to merge Undefined Behavior Sanitizer in


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.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]