From: Paolo Bonzini <bonzini@gnu.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
gcc-patches@gcc.gnu.org, marcandre.lureau@redhat.com,
mliska@suse.cz
Subject: Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)
Date: Tue, 13 Feb 2018 12:55:00 -0000 [thread overview]
Message-ID: <f5abcb64-a208-1027-1935-5d7219ce2e15@gnu.org> (raw)
In-Reply-To: <20180212234921.GN5867@tucnak>
On 13/02/2018 00:49, Jakub Jelinek wrote:
> On Tue, Feb 13, 2018 at 12:41:28AM +0100, Paolo Bonzini wrote:
>> On 09/02/2018 19:07, Jakub Jelinek wrote:
>>> On Fri, Feb 09, 2018 at 07:01:08PM +0100, Richard Biener wrote:
>>>>> which indeed fixes the testcase and seems not to break asan.exp.
>>>>
>>>> Huh. Need to double check why that makes sense ;)
>>>
>>> I think it does, for both ASAN_CHECK and ASAN_MARK the pointer argument
>>> is the second one, the first one is an integer argument with flags.
>>> And ASAN_MARK, both poison and unpoison, works kind like a clobber on the
>>> referenced variable, before unpoison it is generally inaccessible and after
>>> poison too.
>>
>> This was too optimistic. :(
>>
>> In use-after-scope-types-1.C, after the patch FRE+DSE are able to
>> optimize away the problematic read. In general it seems to me that the
>> sanitizer passes should be before DSE if we want ASAN builtins to have
>> precise info, otherwise some reads or stores might not be
>> instrumented---GCC was being lucky here.
>>
>> The obvious change here is:
>
> That is way too early, I don't think this is a good idea.
> Certainly not in stage4.
Certainly, for now I'll revert.
But can you expand on why it's too early? Indeed I suppose it may
affect inlining decisions, on the other hand it seems dangerous to apply
instrumentation after pretty much any optimization pass.
Thanks,
Paolo
next prev parent reply other threads:[~2018-02-13 12:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 16:08 Paolo Bonzini
2018-02-09 16:40 ` Richard Biener
2018-02-09 17:23 ` Paolo Bonzini
2018-02-09 18:01 ` Richard Biener
2018-02-09 18:37 ` Jakub Jelinek
2018-02-09 20:10 ` Richard Biener
2018-02-12 8:57 ` Richard Biener
2018-02-12 12:02 ` Paolo Bonzini
2018-02-12 12:10 ` Jakub Jelinek
2018-02-13 9:33 ` Fallout: PR84340 Martin Liška
2018-02-13 11:16 ` Paolo Bonzini
2018-02-13 13:49 ` Jakub Jelinek
2018-02-13 14:49 ` Jakub Jelinek
2018-02-13 15:22 ` Paolo Bonzini
2018-02-13 16:48 ` Martin Liška
2018-02-16 9:54 ` Martin Liška
2018-02-16 10:49 ` Jakub Jelinek
2018-02-16 10:58 ` Martin Liška
2018-02-16 15:49 ` Jakub Jelinek
2018-02-12 23:41 ` [PATCH] Improve dead code elimination with -fsanitize=address (PR84307) Paolo Bonzini
2018-02-13 11:49 ` Jakub Jelinek
2018-02-13 12:55 ` Paolo Bonzini [this message]
2018-02-13 13:49 ` Jakub Jelinek
2018-02-13 14:29 ` Paolo Bonzini
2018-02-09 18:37 ` Jakub Jelinek
2018-02-13 18:49 ` Jakub Jelinek
2018-02-14 21:49 ` [PATCH] Fix up compound literal handling in C FE (PR sanitizer/84307) Jakub Jelinek
2018-02-14 22:03 ` Joseph Myers
2018-02-26 10:01 ` Martin Liška
2018-02-26 10:49 ` Jakub Jelinek
2018-02-26 10:05 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5abcb64-a208-1027-1935-5d7219ce2e15@gnu.org \
--to=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mliska@suse.cz \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).