[PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
Hi!
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.
Or one can use -fsanitize-undefined-trap-on-error, which will just
__builtin_trap () on undefined behavior, not report anything and not require
linking of -lubsan (useful e.g. for the kernel or embedded apps).
If -fsanitize-undefined-trap-on-error, then -f{,no-}sanitize-recover
is ignored, as ub traps, of course only the first undefined behavior will
be "reported" (through the SIGILL/abort).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-04-15 Jakub Jelinek
PR sanitizer/60275
* common.opt (fsanitize-recover, fsanitize-undefined-trap-on-error):
New options.
* gcc.c (sanitize_spec_function): Don't return "" for "undefined"
if flag_sanitize_undefined_trap_on_error.
* sanitizer.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT,
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS_ABORT,
BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE_ABORT,
BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_ABORT,
BUILT_IN_UBSAN_HANDLE_ADD_OVERFLOW_ABORT,
BUILT_IN_UBSAN_HANDLE_SUB_OVERFLOW_ABORT,
BUILT_IN_UBSAN_HANDLE_MUL_OVERFLOW_ABORT,
BUILT_IN_UBSAN_HANDLE_NEGATE_OVERFLOW_ABORT,
BUILT_IN_UBSAN_HANDLE_LOAD_INVALID_VALUE_ABORT): New builtins.
* ubsan.c (ubsan_instrument_unreachable): Return
__builtin_trap () if flag_sanitize_undefined_trap_on_error.
(ubsan_expand_null_ifn): Emit __builtin_trap ()
if flag_sanitize_undefined_trap_on_error and
__ubsan_handle_type_mismatch_abort if !flag_sanitize_recover.
(ubsan_expand_null_ifn, ubsan_build_overflow_builtin,
instrument_bool_enum_load): Emit __builtin_trap () if
flag_sanitize_undefined_trap_on_error and
__builtin_handle_*_abort () if !flag_sanitize_recover.
* doc/invoke.texi (-fsanitize-recover,
-fsanitize-undefined-trap-on-error): Document.
c-family/
* c-ubsan.c (ubsan_instrument_return): Return __builtin_trap ()
if flag_sanitize_undefined_trap_on_error.
(ubsan_instrument_division, ubsan_instrument_shift,
ubsan_instrument_vla): Likewise. Use __ubsan_handle_*_abort ()
if !flag_sanitize_recover.
testsuite/
* g++.dg/ubsan/return-2.C: Revert 2014-03-24 changes, add
-fno-sanitize-recover to dg-options.
* g++.dg/ubsan/cxx11-shift-1.C: Remove c++11 target restriction,
add -std=c++11 to dg-options.
* g++.dg/ubsan/cxx11-shift-2.C: Likewise.
* g++.dg/ubsan/cxx1y-vla.C: Remove c++1y target restriction,
add -std=c++1y to dg-options.
* c-c++-common/ubsan/undefined-1.c: Revert 2014-03-24 changes, add
-fno-sanitize-recover to dg-options.
* c-c++-common/ubsan/overflow-sub-1.c: Likewise.
* c-c++-common/ubsan/vla-4.c: Likewise.
* c-c++-common/ubsan/pr59503.c: Likewise.
* c-c++-common/ubsan/vla-3.c: Likewise.
* c-c++-common/ubsan/save-expr-1.c: Likewise.
* c-c++-common/ubsan/overflow-add-1.c: Likewise.
* c-c++-common/ubsan/shift-3.c: Likewise.
* c-c++-common/ubsan/overflow-1.c: Likewise.
* c-c++-common/ubsan/overflow-negate-2.c: Likewise.
* c-c++-common/ubsan/vla-2.c: Likewise.
* c-c++-common/ubsan/overflow-mul-1.c: Likewise.
* c-c++-common/ubsan/pr60613-1.c: Likewise.
* c-c++-common/ubsan/shift-6.c: Likewise.
* c-c++-common/ubsan/overflow-mul-3.c: Likewise.
* c-c++-common/ubsan/overflow-add-3.c: New test.
* c-c++-common/ubsan/overflow-add-4.c: New test.
* c-c++-common/ubsan/div-by-zero-6.c: New test.
* c-c++-common/ubsan/div-by-zero-7.c: New test.
--- gcc/common.opt.jj 2014-04-15 09:57:33.400264838 +0200
+++ gcc/common.opt 2014-04-15 10:28:10.554519376 +0200
@@ -862,6 +862,14 @@ fsanitize=
Common Driver Report Joined
Select what to sanitize
+fsanitize-recover
+Common Report Var(flag_sanitize_recover) Init(1)
+After diagnosing undefined behavior attempt to continue execution
+
+fsanitize-undefined-trap-on-error
+Common Report Var(flag_sanitize_undefined_trap_on_error) Init(0)
+Use trap instead of a library function for undefined behavior sanitization
+
fasynchronous-unwind-tables
Common Report Var(flag_asynchronous_unwind_tables) Optimization
Generate unwind tables that are exact at each instruction boundary
--- gcc/gcc.c.jj2014-04-15 09:57:33.456264545 +0200
+++ gc
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Tue, 15 Apr 2014, Jakub Jelinek wrote:
> Hi!
>
> 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.
> Or one can use -fsanitize-undefined-trap-on-error, which will just
> __builtin_trap () on undefined behavior, not report anything and not require
> linking of -lubsan (useful e.g. for the kernel or embedded apps).
> If -fsanitize-undefined-trap-on-error, then -f{,no-}sanitize-recover
> is ignored, as ub traps, of course only the first undefined behavior will
> be "reported" (through the SIGILL/abort).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Works for me.
Thanks,
Richard.
> 2014-04-15 Jakub Jelinek
>
> PR sanitizer/60275
> * common.opt (fsanitize-recover, fsanitize-undefined-trap-on-error):
> New options.
> * gcc.c (sanitize_spec_function): Don't return "" for "undefined"
> if flag_sanitize_undefined_trap_on_error.
> * sanitizer.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT,
> BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS_ABORT,
> BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE_ABORT,
> BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_ABORT,
> BUILT_IN_UBSAN_HANDLE_ADD_OVERFLOW_ABORT,
> BUILT_IN_UBSAN_HANDLE_SUB_OVERFLOW_ABORT,
> BUILT_IN_UBSAN_HANDLE_MUL_OVERFLOW_ABORT,
> BUILT_IN_UBSAN_HANDLE_NEGATE_OVERFLOW_ABORT,
> BUILT_IN_UBSAN_HANDLE_LOAD_INVALID_VALUE_ABORT): New builtins.
> * ubsan.c (ubsan_instrument_unreachable): Return
> __builtin_trap () if flag_sanitize_undefined_trap_on_error.
> (ubsan_expand_null_ifn): Emit __builtin_trap ()
> if flag_sanitize_undefined_trap_on_error and
> __ubsan_handle_type_mismatch_abort if !flag_sanitize_recover.
> (ubsan_expand_null_ifn, ubsan_build_overflow_builtin,
> instrument_bool_enum_load): Emit __builtin_trap () if
> flag_sanitize_undefined_trap_on_error and
> __builtin_handle_*_abort () if !flag_sanitize_recover.
> * doc/invoke.texi (-fsanitize-recover,
> -fsanitize-undefined-trap-on-error): Document.
> c-family/
> * c-ubsan.c (ubsan_instrument_return): Return __builtin_trap ()
> if flag_sanitize_undefined_trap_on_error.
> (ubsan_instrument_division, ubsan_instrument_shift,
> ubsan_instrument_vla): Likewise. Use __ubsan_handle_*_abort ()
> if !flag_sanitize_recover.
> testsuite/
> * g++.dg/ubsan/return-2.C: Revert 2014-03-24 changes, add
> -fno-sanitize-recover to dg-options.
> * g++.dg/ubsan/cxx11-shift-1.C: Remove c++11 target restriction,
> add -std=c++11 to dg-options.
> * g++.dg/ubsan/cxx11-shift-2.C: Likewise.
> * g++.dg/ubsan/cxx1y-vla.C: Remove c++1y target restriction,
> add -std=c++1y to dg-options.
> * c-c++-common/ubsan/undefined-1.c: Revert 2014-03-24 changes, add
> -fno-sanitize-recover to dg-options.
> * c-c++-common/ubsan/overflow-sub-1.c: Likewise.
> * c-c++-common/ubsan/vla-4.c: Likewise.
> * c-c++-common/ubsan/pr59503.c: Likewise.
> * c-c++-common/ubsan/vla-3.c: Likewise.
> * c-c++-common/ubsan/save-expr-1.c: Likewise.
> * c-c++-common/ubsan/overflow-add-1.c: Likewise.
> * c-c++-common/ubsan/shift-3.c: Likewise.
> * c-c++-common/ubsan/overflow-1.c: Likewise.
> * c-c++-common/ubsan/overflow-negate-2.c: Likewise.
> * c-c++-common/ubsan/vla-2.c: Likewise.
> * c-c++-common/ubsan/overflow-mul-1.c: Likewise.
> * c-c++-common/ubsan/pr60613-1.c: Likewise.
> * c-c++-common/ubsan/shift-6.c: Likewise.
> * c-c++-common/ubsan/overflow-mul-3.c: Likewise.
> * c-c++-common/ubsan/overflow-add-3.c: New test.
> * c-c++-common/ubsan/overflow-add-4.c: New test.
> * c-c++-common/ubsan/div-by-zero-6.c: New test.
> * c-c++-common/ubsan/div-by-zero-7.c: New test.
>
> --- gcc/common.opt.jj 2014-04-15 09:57:33.400264838 +0200
> +++ gcc/common.opt2014-04-15 10:28:10.554519376 +0200
> @@ -862,6 +862,14 @@ fsanitize=
> Common Driver Report Joined
> Select what to sanitize
>
> +fsanitize-recover
> +Common Report Var(flag_sanitize_recover) Init(1)
> +After diagnosing undefined behavior attempt to continue execution
> +
> +fsanitize-undefined-trap-on-error
> +Common Report Var(flag_sanitize_undefined_trap_on_error) Init(0)
> +Use trap instead of a library function for undefined behavior sanitization
> +
> fasynchronous-unwind-tables
> Common Report Var(flag_asynchronous_unwind
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
Jakub Jelinek 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? Thanks, Richard
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote: > Jakub Jelinek 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. Jakub
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
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 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. Marek
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 11:33 AM, Jakub Jelinek wrote: > On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote: >> Jakub Jelinek 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. What's the overhead with bootstrap-ubsan ? Ramana > > Jakub
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
Marek Polacek 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 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
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 01:42:20PM +0100, Richard Sandiford wrote: > > 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. Yeah, I don't like void_zero_node that much; I'll see if I can stamp it out. But note that I see many uses of void_zero_node in the C++ FE. (ubsan uses void_zero_node only in the c-family/ subdirectory.) Marek
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, 15 May 2014, Marek Polacek wrote: > On Thu, May 15, 2014 at 01:42:20PM +0100, Richard Sandiford wrote: > > > 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. > > Yeah, I don't like void_zero_node that much; I'll see if I can stamp it > out. But note that I see many uses of void_zero_node in the C++ FE. > (ubsan uses void_zero_node only in the c-family/ subdirectory.) They shouldn't survive gimplification though. I suggest to add a check for verify_expr to catch them and ICE if they appear in the IL. Richard.
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote: > What's the overhead with bootstrap-ubsan ? I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores, Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results: --enable-languages=all real35m10.419s user204m5.613s sys 6m15.615s --enable-languages=all --with-build-config=bootstrap-ubsan real71m39.338s user347m53.409s sys 7m44.281s Marek
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 05:08:10PM +0200, Marek Polacek wrote: > On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote: > > What's the overhead with bootstrap-ubsan ? > > I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores, > Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results: > > --enable-languages=all > > real 35m10.419s > user 204m5.613s > sys 6m15.615s > > --enable-languages=all --with-build-config=bootstrap-ubsan > > real 71m39.338s > user 347m53.409s > sys 7m44.281s Note that doesn't mean -fsanitize=undefined generated code is twice as slow as code compiled without it, guess most of the extra overhead is actually compile time (mostly larger cfg due to all the extra checks). Jakub
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 05:16:00PM +0200, Jakub Jelinek wrote: > On Thu, May 15, 2014 at 05:08:10PM +0200, Marek Polacek wrote: > > On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote: > > > What's the overhead with bootstrap-ubsan ? > > > > I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores, > > Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results: > > > > --enable-languages=all > > > > real35m10.419s > > user204m5.613s > > sys 6m15.615s > > > > --enable-languages=all --with-build-config=bootstrap-ubsan > > > > real71m39.338s > > user347m53.409s > > sys 7m44.281s > > Note that doesn't mean -fsanitize=undefined generated code is twice as slow > as code compiled without it, guess most of the extra overhead is actually > compile time (mostly larger cfg due to all the extra checks). And I think the main offender will be the NULL checking with its extra bbs. So to alleviate the cfg size one can use -fsanitize=undefined -fno-sanitize=null - I'd expect this to make a significant difference. Marek
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On 05/15/2014 05:08 PM, Marek Polacek wrote: On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote: What's the overhead with bootstrap-ubsan ? I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores, Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results: --enable-languages=all real35m10.419s user204m5.613s sys 6m15.615s --enable-languages=all --with-build-config=bootstrap-ubsan real71m39.338s user347m53.409s sys 7m44.281s And don't underestimate the *usefulness* of this - if you don't have the resources to do a ubsan bootstrap, download mine from last night (x86_64-linux-gnu): http://moene.org/~toon/gcc-tests.log.gz [ I hope there is a way to discard color codings when writing error messages to a file, ugh ] Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 08:32:36PM +0200, Toon Moene wrote: > On 05/15/2014 05:08 PM, Marek Polacek wrote: > > >On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote: > >>What's the overhead with bootstrap-ubsan ? > > > >I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores, > >Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results: > > > >--enable-languages=all > > > >real 35m10.419s > >user 204m5.613s > >sys 6m15.615s > > > >--enable-languages=all --with-build-config=bootstrap-ubsan > > > >real 71m39.338s > >user 347m53.409s > >sys 7m44.281s > > And don't underestimate the *usefulness* of this - if you don't have the > resources to do a ubsan bootstrap, download mine from last night > (x86_64-linux-gnu): http://moene.org/~toon/gcc-tests.log.gz > > [ I hope there is a way to discard color codings when writing error messages > to a file, ugh ] Sure, -fdiagnostics-color=auto "means to use color only when the standard error is a terminal", or -fdiagnostics-color=never to turn it off completely (testsuite uses the latter). Marek
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 08:37:07PM +0200, Marek Polacek wrote: > > And don't underestimate the *usefulness* of this - if you don't have the > > resources to do a ubsan bootstrap, download mine from last night > > (x86_64-linux-gnu): http://moene.org/~toon/gcc-tests.log.gz > > > > [ I hope there is a way to discard color codings when writing error messages > > to a file, ugh ] > > Sure, -fdiagnostics-color=auto "means to use color only when the > standard error is a terminal", or -fdiagnostics-color=never to turn it > off completely (testsuite uses the latter). I guess Toon meant that there is no easy way? to get rid of the color stuff in libsanitizer messages. Jakub
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On 05/15/2014 09:10 PM, Jakub Jelinek wrote: On Thu, May 15, 2014 at 08:37:07PM +0200, Marek Polacek wrote: Sure, -fdiagnostics-color=auto "means to use color only when the standard error is a terminal", or -fdiagnostics-color=never to turn it off completely (testsuite uses the latter). I guess Toon meant that there is no easy way? to get rid of the color stuff in libsanitizer messages. Sure. The point is that the testsuite runs only write to a *file*, so why should I get color-coded error messages like this: ESC[1m/home/toon/compilers/trunk/gcc/config/i386/i386.c:6577:60:ESC[1mESC[31m runtime error: ESC[1mESC[0mESC[1mload of value 32763, which is not a valid value for type 'x86_64_reg_class'ESC[1mESC[0m ? It makes precise grepping needlessly hard ... Otherwise, thanks very much for this work - definitely appreciated ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)
On Thu, May 15, 2014 at 09:10:55PM +0200, Jakub Jelinek wrote: > I guess Toon meant that there is no easy way? to get rid of the color > stuff in libsanitizer messages. Yikes. I think there's no way yet; UBSAN_OPTIONS envvar, similar to e.g. ASAN_OPTIONS, isn't supported yet it seems. Marek
