public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Maxim Kuvyrkov <maxim.kuvyrkov@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [C++ PATCH] Fix -fsanitize={null,alignment} of references (PR c++/79572)
Date: Fri, 24 Nov 2017 14:52:00 -0000	[thread overview]
Message-ID: <CAFrzLAqi1RJ5gBRqX+ejuV9ScWAXbaxQhXJ+pqD6x=hOtv7K8Q@mail.gmail.com> (raw)
In-Reply-To: <20170323203705.GX11094@tucnak>

On Thu, Mar 23, 2017 at 11:37 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> Since late C++ folding has been committed, we don't sanitize some reference
> bindings to NULL.  Earlier we had always NOP_EXPR to REFERENCE_TYPE say from
> INTEGER_CST or whatever else, but cp_fold can now turn that right into
> INTEGER_CST with REFERENCE_TYPE.  The following patch sanitizes even those.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-03-23  Jakub Jelinek  <jakub@redhat.com>
>
>         PR c++/79572
>         * c-ubsan.h (ubsan_maybe_instrument_reference): Change argument to
>         tree *.
>         * c-ubsan.c (ubsan_maybe_instrument_reference): Likewise.  Handle
>         not just NOP_EXPR to REFERENCE_TYPE, but also INTEGER_CST with
>         REFERENCE_TYPE.
>
>         * cp-gimplify.c (cp_genericize_r): Sanitize INTEGER_CSTs with
>         REFERENCE_TYPE.  Adjust ubsan_maybe_instrument_reference caller
>         for NOP_EXPR to REFERENCE_TYPE.
>
>         * g++.dg/ubsan/null-8.C: New test.
>
...
> --- gcc/testsuite/g++.dg/ubsan/null-8.C.jj      2017-03-23 09:42:31.664696676 +0100
> +++ gcc/testsuite/g++.dg/ubsan/null-8.C 2017-03-23 09:43:31.501908802 +0100
> @@ -0,0 +1,19 @@
> +// PR c++/79572
> +// { dg-do run }
> +// { dg-options "-fsanitize=null -std=c++14" }
> +// { dg-output "reference binding to null pointer of type 'const int'" }
> +
> +void
> +foo (const int &iref)
> +{
> +  if (&iref)
> +    __builtin_printf ("iref %d\n", iref);
> +  else
> +    __builtin_printf ("iref is NULL\n");

Hi Jakub,

Using __builtin_printf causes this test to fail sporadically when
cross-testing.  Stdout and stderr output can get mixed in
cross-testing, so dejagnu might see
==
g++.dg/ubsan/null-8.C:18:7: runtime error: reference binding to null
pointer of type iref is NULL
'const int'
==
instead of
==
g++.dg/ubsan/null-8.C:18:7: runtime error: reference binding to null
pointer of type 'const int'
iref is NULL
==

Is it essential for this testcase to use __builtin_printf or simple
"fprintf (stderr, ...)" would do just fine?

> +}
> +
> +int
> +main ()
> +{
> +  foo (*((int*) __null));
> +}

Regards,

-- 
Maxim Kuvyrkov

  reply	other threads:[~2017-11-24 14:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 20:39 Jakub Jelinek
2017-11-24 14:52 ` Maxim Kuvyrkov [this message]
2017-11-24 14:58   ` Jakub Jelinek
2017-11-27 10:49     ` Jakub Jelinek

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='CAFrzLAqi1RJ5gBRqX+ejuV9ScWAXbaxQhXJ+pqD6x=hOtv7K8Q@mail.gmail.com' \
    --to=maxim.kuvyrkov@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).