On Sat, 13 Jul 2013, Jakub Jelinek wrote:
> Here is a patch that implements that (of course on top of Marek's patch from
> June).
>
> 2013-07-13 Jakub Jelinek
>
> * gcc.c: Document %{%:function(args):X}.
> (SANITIZER_EARLY_SPEC, SANITIZER_SPEC): Use %:sanitize(address)
> ins
On Sat, Jul 13, 2013 at 11:47:29PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 10:17:15AM +0200, Jakub Jelinek wrote:
> > While it would be possible to define say %:sanitize(thread LIBTSAN_EARLY)
> > that would work roughly like %{fsanitize=thread:LIBTSAN_EARLY} worked
> > until now (vari
On Wed, Jun 19, 2013 at 10:17:15AM +0200, Jakub Jelinek wrote:
> While it would be possible to define say %:sanitize(thread LIBTSAN_EARLY)
> that would work roughly like %{fsanitize=thread:LIBTSAN_EARLY} worked
> until now (variable number of arguments that would be concatenated together
> if flag_
On Wed, Jun 19, 2013 at 10:45:28AM +0200, Richard Biener wrote:
> 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
On Tue, Jun 18, 2013 at 10:25 PM, 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
On Tue, Jun 18, 2013 at 10:45:53PM +, Joseph S. Myers wrote:
> 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
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
> in
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
%{fsanit
On Mon, Jun 17, 2013 at 06:01:10PM +0200, Jakub Jelinek wrote:
> On Mon, Jun 17, 2013 at 03:52:54PM +, Joseph S. Myers wrote:
> > On Mon, 17 Jun 2013, Jakub Jelinek wrote:
> >
> > > > +; What the sanitizer should instrument
> > > > +Variable
> > > > +unsigned int flag_sanitize
> > >
> > > Can
On Mon, Jun 17, 2013 at 03:52:54PM +, Joseph S. Myers wrote:
> On Mon, 17 Jun 2013, Jakub Jelinek wrote:
>
> > > +; What the sanitizer should instrument
> > > +Variable
> > > +unsigned int flag_sanitize
> >
> > Can't you just add Var(flag_sanitize) to the line after fsanitize= ?
>
> I think
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
> > +; What the sanitizer should instrument
> > +Variable
> > +unsigned int flag_sanitize
>
> Can't you just add Var(flag_sanitize) to the line after fsanitize= ?
I think that would create a string variable, whereas an integer is what's
wanted here.
--
Hi!
Looks good, though I'd appreciate Joseph to look at this from the
option handling POV. Some nits from me below:
On Fri, Jun 14, 2013 at 09:04:40PM +0200, Marek Polacek wrote:
> --- gcc/opts.c.mp 2013-06-14 19:23:02.300554991 +0200
> +++ gcc/opts.c2013-06-14 20:00:30.377638168 +02
This patch is needed mainly for ubsan, but since it is an independent
change, I'd like to get this one into trunk. It adds proper parsing of the
-fsanitize= option, currently -fsanitize=thread and -fsanitize=address
are "hardcoded" in common.opt. It allows user to specify what exactly
to instrume
13 matches
Mail list logo
