This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Request to merge Undefined Behavior Sanitizer in
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Jason Merrill <jason at redhat dot com>
- Date: Thu, 25 Jul 2013 22:33:46 -0700
- Subject: Re: Request to merge Undefined Behavior Sanitizer in
- References: <20130725153227 dot GC32538 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1307252236460 dot 24818 at digraph dot polyomino dot org dot uk> <51F20006 dot 6040705 at redhat dot com>
On Thu, Jul 25, 2013 at 9:50 PM, Jeff Law <law@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
>
>