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_
40 matches
Mail list logo
