On Tue, 18 Jun 2013, Jakub Jelinek 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?
Try defining a new spec function or functions that uses flag_sanitize to
determine what linker arguments to pass? Since the option handling is in
opts.c it should get run in the driver so flag_sanitize should be set
correctly there; as long as the specs in question run after the relevant
option processing, a spec function should work for this.
--
Joseph S. Myers
jos...@codesourcery.com
