public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <bonzini@gnu.org>
To: Richard Biener <richard.guenther@gmail.com>, 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 17:23:00 -0000	[thread overview]
Message-ID: <2bd36577-88f0-2926-d777-ee9a11d315f4@gnu.org> (raw)
In-Reply-To: <B22374CA-583E-4779-9D84-73AC7F76ECF2@gmail.com>

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.
'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 17:23 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 [this message]
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
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=2bd36577-88f0-2926-d777-ee9a11d315f4@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).