On Tue, Jun 18, 2013 at 10:25 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Jun 18, 2013 at 04:42:51PM +0200, Marek Polacek wrote:
>> Ok, should be done now (together with other nit-fixes).
>> Regtested/bootstrapped on x86_64-linux, ok for trunk?
>
> Looks good to me, the only thing I'm worried about are how this
> interferes with the
> %{fsanitize=address:...}
> and
> %{fsanitize=thread:...}
> bits in gcc.c. Because we should link in -lasan even for
> -fsanitize=shift,address,undefined
> and should not link in -lasan for
> -fsanitize=address -fno-sanitize=undefined,address,shift
> (generally, what we have guarded right now with
> %{fsanitize=address:...}
> should be done if flag_sanitize & SANITIZE_ADDRESS is going to be
> true in the end, etc., and we'll need to link in
> -lubsan whenever at least one of the undefined options are set in the
> bitmask. -lubsan isn't incompatible with -lasan nor -ltsan, but -lasan
> and -ltsan are incompatible.
>
> Joseph, any thoughts how to deal with this?
Btw, how to handle the issue with LTO and different -fsanitize options
at compile vs. link-time? Can TUs without -fsanitize options be LTO
linked with -fsanitize? Then lto-wrapper should union -fsanitize
options from all TUs to the final link. I hope all -fsanitize options can
be mixed freely and will properly combine.
Richard.
> Jakub
