This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix sanitization ICE (PR c++/80973)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Nathan Sidwell <nathan at acm dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 12 Jun 2017 13:04:16 +0200
- Subject: Re: [C++ PATCH] Fix sanitization ICE (PR c++/80973)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 39B90C04B320
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 39B90C04B320
- References: <20170608193018.GD2154@tucnak> <CADzB+2=8P337ZXaHKmTUBAGm1m0YV7_1LA+uUa9qcg+3g0bSwQ@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jun 09, 2017 at 12:30:10PM -0700, Jason Merrill wrote:
> On Thu, Jun 8, 2017 at 12:30 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > cp_genericize_r now instruments INTEGER_CSTs that have REFERENCE_TYPE,
> > so that we can diagnose binding references to NULL in some cases,
> > see PR79572. As the following testcase shows, there is one exception
> > when we do not want to do that - in MEM_EXPR, the second operand
> > is an INTEGER_CST whose value is an offset, but type is something
> > unrelated - what should be used for aliasing purposes. So, that
> > is something we do not want to diagnose, and it is also invalid IL,
> > as the second argument has to be an INTEGER_CST, not some expression
> > with side-effects.
> >
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> > ok for trunk/7.x?
> >
> > PR c++/80973
> > * cp-gimplify.c (cp_genericize_r): Don't instrument MEM_REF second
> > argument even if it has REFERENCE_TYPE.
>
> I wonder if we want to handle this in walk_tree_1, so all tree walks
> by default avoid the second operand.
MEM_REF has the second argument and there could be callbacks that really
want to walk even that argument for whatever reason (gather all types
mentioned in some expression, whatever). Implying from one place where
we do not want that what other code might want to do doesn't look right.
But, if you want, the patch could be simplified, handle the MEM_REF
in there this way unconditionally, so:
else if (TREE_CODE (stmt) == MEM_REF)
{
cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_genericize_r, data, NULL);
*walk_subtrees = 0;
}
before the sanitizer block, perhaps with some comments explaining it,
because we know cp_genericize_r doesn't need to have the callback
on the second MEM_REF argument.
Jakub