On Tue, Nov 08, 2016 at 10:38:23AM +0100, Martin Liška wrote:
> > I believe the 0 here is a bug, I'd think we should be using something like
> > ATTR_TMPURE_NOTHROW_LEAF_LIST that we are using __asan_load* - the functions
> > aren't going to throw, nor call anything in the current TU. Not 100% sur
On 11/07/2016 05:17 PM, Jakub Jelinek wrote:
> On Mon, Nov 07, 2016 at 11:07:13AM -0500, David Malcolm wrote:
>> The patch (r241896) introduced an error in the build of the jit:
>>
>> ../../src/gcc/jit/jit-builtins.c:62:1: error: invalid conversion from
>> ‘int’ to ‘gcc::jit::built_in_attribute’ [-
On Mon, Nov 07, 2016 at 11:07:13AM -0500, David Malcolm wrote:
> The patch (r241896) introduced an error in the build of the jit:
>
> ../../src/gcc/jit/jit-builtins.c:62:1: error: invalid conversion from
> ‘int’ to ‘gcc::jit::built_in_attribute’ [-fpermissive]
> };
> ^
>
> which seems to be due
On Mon, 2016-11-07 at 11:03 +0100, Martin Liška wrote:
> Hello.
>
> After discussion with Jakub, I'm resending new version of the patch,
> where I changed following:
> 1) gimplify_ctxp->live_switch_vars is used to track variables
> introduced in switch_expr. Every time
>a case_label_expr is se
On Mon, Nov 07, 2016 at 11:03:11AM +0100, Martin Liška wrote:
> Hello.
>
> After discussion with Jakub, I'm resending new version of the patch, where I
> changed following:
> 1) gimplify_ctxp->live_switch_vars is used to track variables introduced in
> switch_expr. Every time
>a case_label_e
Hello.
After discussion with Jakub, I'm resending new version of the patch, where I
changed following:
1) gimplify_ctxp->live_switch_vars is used to track variables introduced in
switch_expr. Every time
a case_label_expr is seen, these are unpoisoned. It's quite conservative,
however it cove
On 11/04/2016 10:32 AM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Nov 04, 2016 at 10:17:31AM +0100, Martin Liška wrote:
>> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
>> index 813777d..86ce793 100644
>> --- a/gcc/gimplify.c
>> +++ b/gcc/gimplify.c
>> @@ -1678,7 +1678,9 @@ warn_switch_unreachable_r (
Hi!
On Fri, Nov 04, 2016 at 10:17:31AM +0100, Martin Liška wrote:
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index 813777d..86ce793 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -1678,7 +1678,9 @@ warn_switch_unreachable_r (gimple_stmt_iterator *gsi_p,
> bool *handled_ops_p,
>
On 11/02/2016 03:35 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 03:27:42PM +0100, Martin Liška wrote:
>>> So is there anything I should do wrt -Wswitch-unreachable?
>>>
>>> Marek
>>>
>>
>> Probably not. I'm having a patch puts GIMPLE_SWITCH statement to a proper
>> place
>> in GIMPLE_BI
On 11/03/2016 03:03 PM, Jakub Jelinek wrote:
> On Thu, Nov 03, 2016 at 03:02:21PM +0100, Martin Liška wrote:
>>> But how would you be able to find out if there isn't any return *ptr; after
>>> the scope or similar (as MEM_REF)? With is_gimple_reg, they will be turned
>>> into SSA form and you can
On Thu, Nov 03, 2016 at 03:02:21PM +0100, Martin Liška wrote:
> > But how would you be able to find out if there isn't any return *ptr; after
> > the scope or similar (as MEM_REF)? With is_gimple_reg, they will be turned
> > into SSA form and you can easily verify (uses of ASAN_POISON are a proble
On 11/03/2016 02:44 PM, Jakub Jelinek wrote:
> Hi!
>
> FYI, I think it is much more important to get the initial patch in, so
> resolve the switch + declarations inside of its body stuff, add testcases
> for that and post for re-review and check in.
> These optimizations can be done even in stage3
Hi!
FYI, I think it is much more important to get the initial patch in, so
resolve the switch + declarations inside of its body stuff, add testcases
for that and post for re-review and check in.
These optimizations can be done even in stage3.
On Thu, Nov 03, 2016 at 02:34:47PM +0100, Martin Liška
On 11/02/2016 03:51 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 03:38:25PM +0100, Martin Liška wrote:
>> it converts:
>> foo ()
>> {
>> char a;
>> char * p;
>> char _1;
>> int _2;
>> int _8;
>> int _9;
>>
>> :
>> ASAN_MARK (2, &a, 1);
>> a = 0;
>> p_6 = &a;
>> ASAN_MARK
On 11/02/2016 03:51 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 03:38:25PM +0100, Martin Liška wrote:
>> it converts:
>> foo ()
>> {
>> char a;
>> char * p;
>> char _1;
>> int _2;
>> int _8;
>> int _9;
>>
>> :
>> ASAN_MARK (2, &a, 1);
>> a = 0;
>> p_6 = &a;
>> ASAN_MARK
On Wed, Nov 02, 2016 at 03:38:25PM +0100, Martin Liška wrote:
> it converts:
> foo ()
> {
> char a;
> char * p;
> char _1;
> int _2;
> int _8;
> int _9;
>
> :
> ASAN_MARK (2, &a, 1);
> a = 0;
> p_6 = &a;
> ASAN_MARK (1, &a, 1);
> _1 = *p_6;
You shouldn't convert if a is ad
On 11/02/2016 02:16 PM, Richard Biener wrote:
> On Wed, Nov 2, 2016 at 2:06 PM, Jakub Jelinek wrote:
>> On Wed, Nov 02, 2016 at 01:59:00PM +0100, Richard Biener wrote:
Yeah, that is what I meant. The issue is how to report uses of such
SSA_NAME when there is no memory. So, either we'd
On Wed, Nov 02, 2016 at 03:27:42PM +0100, Martin Liška wrote:
> > So is there anything I should do wrt -Wswitch-unreachable?
> >
> > Marek
> >
>
> Probably not. I'm having a patch puts GIMPLE_SWITCH statement to a proper
> place
> in GIMPLE_BIND. Let's see whether such patch can bootstrap a
On 11/02/2016 03:20 PM, Marek Polacek wrote:
> On Wed, Nov 02, 2016 at 11:10:53AM +0100, Jakub Jelinek wrote:
>> On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote:
Which is gimplified as:
int * ptr;
switch (argc) , case 1: >
{
int a;
On Wed, Nov 02, 2016 at 11:10:53AM +0100, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote:
> > > Which is gimplified as:
> > >
> > > int * ptr;
> > >
> > > switch (argc) , case 1: >
> > > {
> > > int a;
> > >
> > > try
> > > {
On Wed, Nov 2, 2016 at 2:06 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 01:59:00PM +0100, Richard Biener wrote:
>> > Yeah, that is what I meant. The issue is how to report uses of such
>> > SSA_NAME when there is no memory. So, either we'd need a special runtime
>> > library entrypoint th
On Wed, Nov 02, 2016 at 01:59:00PM +0100, Richard Biener wrote:
> > Yeah, that is what I meant. The issue is how to report uses of such
> > SSA_NAME when there is no memory. So, either we'd need a special runtime
> > library entrypoint that would report uses after scope even when there is no
> >
On Wed, Nov 2, 2016 at 1:56 PM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 01:36:31PM +0100, Richard Biener wrote:
>> > Unless I'm missing something we either need to perform further analysis
>> > during the addressable subpass - this variable could be made
>> > non-addressable, but is used in
On Wed, Nov 02, 2016 at 01:36:31PM +0100, Richard Biener wrote:
> > Unless I'm missing something we either need to perform further analysis
> > during the addressable subpass - this variable could be made
> > non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA
> > form there
On Wed, Nov 2, 2016 at 10:52 AM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote:
>> > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property
>> > set during the asan pass and kept on until end of compilation of that
>> > function. That me
On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote:
> > Which is gimplified as:
> >
> > int * ptr;
> >
> > switch (argc) , case 1: >
> > {
> > int a;
> >
> > try
> > {
> > ASAN_MARK (2, &a, 4);
> > :
> > goto ;
> >
On 11/02/2016 10:59 AM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:36:44AM +0100, Martin Liška wrote:
>> On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
>>> What kind of false positives it is for each case? Is it with normal
>>> asan-bootstrap (without your -fsanitize-use-after-scope changes),
On Wed, Nov 02, 2016 at 10:36:44AM +0100, Martin Liška wrote:
> On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
> > What kind of false positives it is for each case? Is it with normal
> > asan-bootstrap (without your -fsanitize-use-after-scope changes), or
> > only with those changes, or only with th
On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote:
> > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property
> > set during the asan pass and kept on until end of compilation of that
> > function. That means even if a var only addressable because of ASAN_MARK is
>
On 11/01/2016 04:12 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
>> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>>
>> static void
>> maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
>> -bitmap su
On 11/02/2016 10:40 AM, Richard Biener wrote:
> On Tue, Nov 1, 2016 at 4:12 PM, Jakub Jelinek wrote:
>> On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
>>> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>>>
>>> static void
>>> maybe_optimize_var (tree var, bitmap addresse
On Tue, Nov 1, 2016 at 4:12 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
>> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>>
>> static void
>> maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
>> - b
On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
> What kind of false positives it is for each case? Is it with normal
> asan-bootstrap (without your -fsanitize-use-after-scope changes), or
> only with those changes, or only with those changes and
> -fsanitize-use-after-scope used during bootstrap?
O
On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>
> static void
> maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
> - bitmap suitable_for_renaming)
> + bitmap sui
On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2016 at 03:47:54PM +0100, Martin Liška wrote:
>> On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
>>> Ok for trunk with that change.
>>>
>>> Jakub
>>
>> Hello.
>>
>> I'll commit the patch as soon as following patch would be accepted. Th
On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
> On Thu, Oct 27, 2016 at 04:40:30PM +0200, Martin Liška wrote:
>> On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
>>> On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
> Ok, first let me list some needed follow-ups that don't need to be han
On Tue, Nov 01, 2016 at 03:47:54PM +0100, Martin Liška wrote:
> On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
> > Ok for trunk with that change.
> >
> > Jakub
>
> Hello.
>
> I'll commit the patch as soon as following patch would be accepted. The patch
> fixes false positives when running asan
On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
> Ok for trunk with that change.
>
> Jakub
Hello.
I'll commit the patch as soon as following patch would be accepted. The patch
fixes false positives when running asan-bootstrap.
Patch can bootstrap on ppc64le-redhat-linux and survives regressi
On Thu, Oct 27, 2016 at 04:40:30PM +0200, Martin Liška wrote:
> On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> > On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
> >>> Ok, first let me list some needed follow-ups that don't need to be handled
> >>> right away:
> >>> - r237814-like chan
On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
>>> Ok, first let me list some needed follow-ups that don't need to be handled
>>> right away:
>>> - r237814-like changes for ASAN_MARK
I've spent quite some on that and that's what I begin
On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> My memory is weak, but isn't this something the sanopt pass
> (sanopt_optimize) is already doing similarly for e.g. ASAN_CHECK, UBSAN_NULL
> and UBSAN_VPTR checks? For ASAN_MARK, you actually don't care about any
> calls, those shouldn't unpoison or p
On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
> > Ok, first let me list some needed follow-ups that don't need to be handled
> > right away:
> > - r237814-like changes for ASAN_MARK
>
> Yes, that's missing. I'm wondering whether the same approach would be viable
> as
> the {un}poi
On 10/07/2016 01:13 PM, Jakub Jelinek wrote:
> Hi!
>
Hi Jakub.
Again thanks for detailed review, you found many improvements.
> Ok, first let me list some needed follow-ups that don't need to be handled
> right away:
> - r237814-like changes for ASAN_MARK
Yes, that's missing. I'm wondering whe
Hi!
Ok, first let me list some needed follow-ups that don't need to be handled
right away:
- r237814-like changes for ASAN_MARK
- optimization to remove ASAN_MARK unpoisoning at the start of the function
- optimization to remove ASAN_MARK poisoning at the end of function (and
remove epilogue unp
On Mon, Oct 03, 2016 at 11:27:38AM +0200, Martin Liška wrote:
> > Plus, as I've mentioned before, it would be nice to optimize - for ASAN_MARK
> > unpoison appearing strictly before (i.e. dominating) the first (non-shadow)
> > memory read
> > or write in the function (explicit or possible through
On 08/18/2016 03:36 PM, Jakub Jelinek wrote:
> On Thu, May 12, 2016 at 04:12:21PM +0200, Martin Liška wrote:
>> --- a/gcc/asan.c
>> +++ b/gcc/asan.c
>> @@ -243,6 +243,11 @@ static unsigned HOST_WIDE_INT asan_shadow_offset_value;
>> static bool asan_shadow_offset_computed;
>> static vec sanitized_
On Thu, May 12, 2016 at 04:12:21PM +0200, Martin Liška wrote:
> > Dunno, guess you need to do something in the FE for it already (talk to
> > Jason?). At least in *.original dump there is already:
> > < > save ((const struct IntHolder &) &TARGET_EXPR ) >;
> > int x = (int) saved->val;
On Thu, May 12, 2016 at 04:12:21PM +0200, Martin Liška wrote:
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -243,6 +243,11 @@ static unsigned HOST_WIDE_INT asan_shadow_offset_value;
> static bool asan_shadow_offset_computed;
> static vec sanitized_sections;
>
> +/* Set of variable declarations tha
PING^1
> On 05/12/2016 12:41 PM, Jakub Jelinek wrote:
>> On Wed, May 11, 2016 at 02:54:01PM +0200, Martin Liška wrote:
>>> On 05/06/2016 02:22 PM, Jakub Jelinek wrote:
On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote:
> I've started working on the patch couple of month go, bas
On 05/12/2016 12:41 PM, Jakub Jelinek wrote:
> On Wed, May 11, 2016 at 02:54:01PM +0200, Martin Liška wrote:
>> On 05/06/2016 02:22 PM, Jakub Jelinek wrote:
>>> On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote:
I've started working on the patch couple of month go, basically after
>
On Wed, May 11, 2016 at 02:54:01PM +0200, Martin Liška wrote:
> On 05/06/2016 02:22 PM, Jakub Jelinek wrote:
> > On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote:
> >> I've started working on the patch couple of month go, basically after
> >> a brief discussion with Jakub on IRC.
> >>
>
On 05/06/2016 02:22 PM, Jakub Jelinek wrote:
> On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote:
>> I've started working on the patch couple of month go, basically after
>> a brief discussion with Jakub on IRC.
>>
>> I'm sending the initial version which can successfully run instrumente
On Tue, May 10, 2016 at 05:03:30PM +0200, Martin Liška wrote:
> On 05/06/2016 04:39 PM, Jakub Jelinek wrote:
> > Depends on how exactly it is defined. It could be enabling just its own
> > sanitizer bit and nothing else, then users would need to use
> > -fsanitize=address,use-after-scope
> > or
>
On 05/06/2016 04:39 PM, Jakub Jelinek wrote:
> Depends on how exactly it is defined. It could be enabling just its own
> sanitizer bit and nothing else, then users would need to use
> -fsanitize=address,use-after-scope
> or
> -fsanitize=kernel-address,use-after-scope
I'm inclined to the second op
On Fri, May 06, 2016 at 04:41:41PM +0200, Martin Liška wrote:
> On 05/06/2016 03:25 PM, Jakub Jelinek wrote:
> > Well, we already have the gimple poisoning/unpoisoning code on RTL (emitted
> > after the prologue and before the epilogue), so it shouldn't be that hard.
> > I'd only do the most common
On 05/06/2016 03:25 PM, Jakub Jelinek wrote:
> Well, we already have the gimple poisoning/unpoisoning code on RTL (emitted
> after the prologue and before the epilogue), so it shouldn't be that hard.
> I'd only do the most common/easy cases inline though, like 1/2/4/8/16/32
> bytes long variables.
On Fri, May 06, 2016 at 05:22:46PM +0300, Yury Gribov wrote:
> On 05/06/2016 03:38 PM, Jakub Jelinek wrote:
> >On Fri, May 06, 2016 at 02:48:30PM +0300, Yury Gribov wrote:
> >>>6) As the use-after-scope stuff is already included in libsanitizer, no
> >>>change is needed for the library
> >>
> >>No
On 05/06/2016 03:38 PM, Jakub Jelinek wrote:
On Fri, May 06, 2016 at 02:48:30PM +0300, Yury Gribov wrote:
6) As the use-after-scope stuff is already included in libsanitizer, no change
is needed for the library
Note that upstream seems to use a different cmdline interface. They don't
have a d
On Fri, May 06, 2016 at 03:17:23PM +0200, Martin Liška wrote:
> On 05/06/2016 01:48 PM, Yury Gribov wrote:
> > On 05/06/2016 02:04 PM, Martin Liška wrote:
> >> I've started working on the patch couple of month go, basically after
> >> a brief discussion with Jakub on IRC.
> >>
> >> I'm sending the
On 05/06/2016 01:48 PM, Yury Gribov wrote:
> On 05/06/2016 02:04 PM, Martin Liška wrote:
>> Hello.
>>
>> I've started working on the patch couple of month go, basically after
>> a brief discussion with Jakub on IRC.
>>
>> I'm sending the initial version which can successfully run instrumented
>> tr
On 05/06/2016 02:38 PM, Jakub Jelinek wrote:
> On Fri, May 06, 2016 at 02:48:30PM +0300, Yury Gribov wrote:
>>> 6) As the use-after-scope stuff is already included in libsanitizer, no
>>> change is needed for the library
>>
>> Note that upstream seems to use a different cmdline interface. They don
On Fri, May 06, 2016 at 02:48:30PM +0300, Yury Gribov wrote:
> >6) As the use-after-scope stuff is already included in libsanitizer, no
> >change is needed for the library
>
> Note that upstream seems to use a different cmdline interface. They don't
> have a dedicated -fsanitize=use-after-scope a
On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote:
> I've started working on the patch couple of month go, basically after
> a brief discussion with Jakub on IRC.
>
> I'm sending the initial version which can successfully run instrumented
> tramp3d, postgresql server and Inkscape. It ca
On 05/06/2016 02:04 PM, Martin Liška wrote:
Hello.
I've started working on the patch couple of month go, basically after
a brief discussion with Jakub on IRC.
I'm sending the initial version which can successfully run instrumented
tramp3d, postgresql server and Inkscape. It catches the basic se
Hello.
One more issue I forgot to mention in the previous email:
e) As one can come up with a source code which jumps to a label within
a block scope (use-after-scope-goto-1.c):
// { dg-do run }
// { dg-additional-options "-fsanitize=use-after-scope -fstack-reuse=none" }
int main(int argc, char
Hello.
I've started working on the patch couple of month go, basically after
a brief discussion with Jakub on IRC.
I'm sending the initial version which can successfully run instrumented
tramp3d, postgresql server and Inkscape. It catches the basic set of
examples which are added in following pat
66 matches
Mail list logo
