Marek Polacek <pola...@redhat.com> writes: > On Thu, May 15, 2014 at 12:33:57PM +0200, Jakub Jelinek wrote: >> On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote: >> > Jakub Jelinek <ja...@redhat.com> writes: >> > > This patch adds two new options (compatible with clang) which allow >> > > users to choose the behavior of undefined behavior sanitization. >> > > >> > > By default as before, all undefined behaviors (except for >> > > __builtin_unreachable and missing return in C++) continue after reporting >> > > which means that you can get lots of runtime errors from a single program >> > > run and the exit code will not reflect the failure in that case. >> > > >> > > With this patch, one can use -fsanitize=undefined -fno-sanitize-recover, >> > > which will report just the first undefined behavior and then exit with >> > > non-zero code. >> > >> > Would it make sense for this to be the default for bootstrap-ubsan, >> > so that the bootstrap fails on undefined behaviour? >> >> Perhaps eventually, but is current bootstrap-ubsan really ubsan error free >> on at least the major targets? I've made some efforts towards that goal on >> x86_64-linux, but haven't tried bootstrap-ubsan recently. > > It's not, I'm seeing many > /home/marek/src/gcc/gcc/wide-int.h:1734:7: runtime error: shift > exponent 64 is too large for 64-bit type 'long unsigned int' > plus I think I remember some other fails.
Yeah, like Richard said on IRC a few days ago, this is partly due to the zero-precision stuff. We need to ween ubsan off void_zero_node and then see where things stand. Thanks, Richard
