On 01/25/2016 09:30 PM, Jakub Jelinek wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
I've been staring at it for a while, and on the whole I think I can make
sense of this. However - it does not have test coverage. Can this be
added? Also, is this a regression?
(parse_sanitizer_options): New function.
(common_handle_option): Use parse_sanitizer_options.
I think this can go in, it just moves code around, right? That'll make
followup patches smaller.
--- gcc/lto-opts.c.jj 2016-01-23 00:13:00.897015402 +0100
+++ gcc/lto-opts.c 2016-01-25 14:06:31.834127398 +0100
@@ -199,9 +199,11 @@ lto_write_options (void)
/* Also drop all options that are handled by the driver as well,
which includes things like -o and -v or -fhelp for example.
We do not need those. The only exception is -foffload option, if we
- write it in offload_lto section. Also drop all diagnostic options. */
+ write it in offload_lto section. Also drop all diagnostic options,
+ and -fsanitize=. */
if ((cl_options[option->opt_index].flags & (CL_DRIVER|CL_WARNING))
- && (!lto_stream_offload_p || option->opt_index != OPT_foffload_))
+ && (!lto_stream_offload_p || option->opt_index != OPT_foffload_)
+ && option->opt_index != OPT_fsanitize_)
continue;
This one puzzles me, doesn't it mean that no sanitizer options make it
into the LTO stream, which would mean the new code in lto-wrapper
doesn't trigger?
+/* Set *OPT to decoded -f{,no-}sanitize=shift. */
I think I'd like some sort of comment about how this is an arbitrary
choice, just designed to enable DEF_SANITIZER_BUILTIN (IIUC). Also, why
use shift and not just sanitize=undefined?
@@ -392,6 +415,24 @@ merge_and_complain (struct cl_decoded_op
break;
}
}
+
+ /* If FDECODED_OPTIONS requested any ubsan sanitization, pass through
I think we want to add "and DECODED_OPTIONS doesn't", right?
Bernd
