This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Small type_hash_canon improvement
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 5 May 2017 09:09:55 +0200
- Subject: Re: [PATCH] Small type_hash_canon improvement
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.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 553DC8123A
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 553DC8123A
- References: <20170504144345.GS1809@tucnak> <D3E8F88D-EE49-4277-AEFD-91C623F7CC1E@suse.de> <20170504160346.GU1809@tucnak> <4EFD0D03-48A9-4AD3-B7E8-A185D90E4518@suse.de> <20170504162700.GV1809@tucnak>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, May 04, 2017 at 06:27:00PM +0200, Jakub Jelinek wrote:
> On Thu, May 04, 2017 at 06:21:17PM +0200, Richard Biener wrote:
> > >the
> > >only other user after all calls free_node in a loop, so it is highly
> > >unlikely it would do anything there.
> > >
> > >If you mean the INTEGER_TYPE handling, then yes, I guess it could be
> > >done in free_node too and can move it there. If it was without
> > >the && TREE_TYPE (TYPE_M*_VALUE (type)) == type extra checks, then it
> > >is certainly unsafe and breaks bootstrap even, e.g. build_range_type
> > >and other spots happily create INTEGER_TYPEs with min/max value that
> > >have some other type. But when the type of the INTEGER_CSTs is the
> > >type we are ggc_freeing, anything that would refer to those constants
> > >afterwards would be necessarily broken (as their TREE_TYPE would be
> > >ggc_freed, possibly reused for something completely unrelated).
> > >Thus I think it should be safe even in the LTO case and thus doable
> > >in free_node.
> >
> > OK. OTOH LTO frees the whole SCC and thus doesn't expect any pointed to stuff
> > to be freed. Not sure if we allow double ggc_free of stuff.
>
> We don't, that crashes miserably.
Tried that patch (moving the INTEGRAL_TYPE handling into free_node), and got
246 new FAILs in -flto testcases.
Jakub