[Bug lto/89692] [9 Regression] ICE in streamer_write_chain, at tree-streamer-out.c:506

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Wed Mar 20 15:05:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692

--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 20 Mar 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692
> 
> --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #12)
> > All varaints have the same TYPE_CANONICAL, that of the main variant, and
> > we never throw away the main variant.  Basically
> > 
> > gcc_assert (TYPE_CANONICAL (t) == TYPE_MAIN_VARIANT (TYPE_CANONICAL (t)) 
> > == TYPE_CANONICAL (TYPE_MAIN_VARAINT (t)))
> > 
> > holds
> 
> If it holds, then no objection from me, I just wonder how far we'd get in a
> bootstrap (including say Ada) if we've added that assert somewhere.
> But in that case the comment that 
>       /* Do not walk TYPE_CANONICAL.  We do not stream it and thus do not
>          and want not to reach unused types this way.  */
> doesn't make much sense, because fld_worklist_push (TYPE_CANONICAL (t), fld);
> wouldn't change anything.

Theoretically TYPE_CANONICAL might point to an "unrelated" type, since
we re-build TYPE_CANONICAL with LTO rules the comment does make sense.

Of course the non-LTO compilation continues here so indeed that could
leave types unvisited that are reached by TYPE_CANONICAL during
the compilation up to stream-out (and into fat part compilation).
So yes, we should probably visit TYPE_CANONICAL here.


More information about the Gcc-bugs mailing list