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 ja...@redhat.com
* gcc.c: Document %{%:function(args):X}.
(SANITIZER_EARLY_SPEC, SANITIZER_SPEC): Use %:sanitize(address)
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
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 (variable
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, 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
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 to
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't you just add
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
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
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
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.
--
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 that would
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
13 matches
Mail list logo
