public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Paolo Bonzini <bonzini@gnu.org>,gcc-patches@gcc.gnu.org
Cc: marcandre.lureau@redhat.com,jakub@redhat.com,mliska@suse.cz
Subject: Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)
Date: Fri, 09 Feb 2018 18:01:00 -0000	[thread overview]
Message-ID: <4FD5AE20-78E2-4741-A6CB-EA2B0AA3514F@gmail.com> (raw)
In-Reply-To: <2bd36577-88f0-2926-d777-ee9a11d315f4@gnu.org>

On February 9, 2018 6:23:37 PM GMT+01:00, Paolo Bonzini <bonzini@gnu.org> wrote:
>On 09/02/2018 17:40, Richard Biener wrote:
>> On February 9, 2018 5:08:24 PM GMT+01:00, Paolo Bonzini
><bonzini@gnu.org> wrote:
>>> Another possibility which I considered but did not implement is to
>mark
>>> the UNPOISON calls so that they do not cause the parameter to
>escape.
>> 
>> I'd do this, thus assign proper fnspec attributes to the asan
>functions. 
>
>Hmm, actually that might be as simple as fixing a typo:
>
>diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
>index 5970d0e..15d6151 100644
>--- a/gcc/internal-fn.def
>+++ b/gcc/internal-fn.def
>@@ -255,8 +255,8 @@ DEF_INTERNAL_FN (UBSAN_PTR, ECF_LEAF | ECF_NOTHROW,
>".R.")
> DEF_INTERNAL_FN (UBSAN_OBJECT_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
> DEF_INTERNAL_FN (ABNORMAL_DISPATCHER, ECF_NORETURN, NULL)
>DEF_INTERNAL_FN (BUILTIN_EXPECT, ECF_CONST | ECF_LEAF | ECF_NOTHROW,
>NULL)
>-DEF_INTERNAL_FN (ASAN_CHECK, ECF_TM_PURE | ECF_LEAF | ECF_NOTHROW,
>".R...")
>-DEF_INTERNAL_FN (ASAN_MARK, ECF_LEAF | ECF_NOTHROW, ".R..")
>+DEF_INTERNAL_FN (ASAN_CHECK, ECF_TM_PURE | ECF_LEAF | ECF_NOTHROW,
>"..R..")
>+DEF_INTERNAL_FN (ASAN_MARK, ECF_LEAF | ECF_NOTHROW, "..W.")
>DEF_INTERNAL_FN (ASAN_POISON, ECF_LEAF | ECF_NOTHROW | ECF_NOVOPS,
>NULL)
>DEF_INTERNAL_FN (ASAN_POISON_USE, ECF_LEAF | ECF_NOTHROW | ECF_NOVOPS,
>NULL)
>DEF_INTERNAL_FN (ADD_OVERFLOW, ECF_CONST | ECF_LEAF | ECF_NOTHROW,
>NULL)
>
>which indeed fixes the testcase and seems not to break asan.exp.

Huh. Need to double check why that makes sense ;) 

>'W' is needed to avoid breaking the pr78541.c testcase, and I think it
>makes sense since ASAN_MARK is "writing" the state of the object
>(in the test case FRE moves a dereference across a poisoning).
>
>I'll look at it next week.  Someone maybe should take a look at ubsan
>fnspecs too.
>
>Paolo

  reply	other threads:[~2018-02-09 18:01 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 [this message]
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
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=4FD5AE20-78E2-4741-A6CB-EA2B0AA3514F@gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=bonzini@gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mliska@suse.cz \
    /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).