> On Fri, 2020-10-23 at 21:45 +0200, Jan Hubicka wrote:
> > Hi,
> > this patch moves thunk_info out of cgraph_node into a symbol summary.
> > I also moved it to separate hearder file since cgraph.h became really
> > too
> > fat. I plan to contiue with similar breakup in order to cleanup
> > interfaces
> > and reduce WPA memory footprint (symbol table now consumes more
> > memory than
> > trees)
> >
> > Bootstrapped/regtested x86_64-linux, plan to commit it shortly.
>
> This seems to have broken libgccjit (specifically, code that makes
> function calls). Please can you test with --enable-languages=all,jit
> (as "jit" isn't part of "all", since it needs --enable-host-shared).
Sorry for that :(
I wl try to keep in mind and test JIT.
>
> [...snip...]
>
> > +/* Return thunk_info possibly creating new one. */
> > +thunk_info *
> > +thunk_info::get_create (cgraph_node *node)
> > +{
> > + if (!symtab->m_thunks)
> > + {
> > + symtab->m_thunks
> > + = new (ggc_alloc_no_dtor <thunk_infos_t> ())
> > + thunk_infos_t (symtab, true);
> > + symtab->m_thunks->disable_insertion_hook ();
> > + }
> > + return symtab->m_thunks->get_create (node);
> > +}
>
> symtab->m_thunks is allocated via ggc_alloc_no_dtor here, thus
> allocating it within the GC heap...
>
> [...snip...]
>
> > +/* Free thunk info summaries. */
> > +inline void
> > +thunk_info::release ()
> > +{
> > + if (symtab->m_thunks)
> > + delete (symtab->m_thunks);
> > + symtab->m_thunks = NULL;
> > +}
>
> ...but deallocated using plain "delete", attempting to release the GC-
> allocated memory into the system heap, leading to an ICE. This seems
> to happen for any compilation of function calls in which
> toplev::finalize is called, i.e. any compilation of function calls from
> libgccjit.
>
> Does it need to be in the GC heap (maybe for PCH?), or can it be simply
> allocated in the system heap via regular "new"?
It points to trees (alias decl) and thus it is in PCH so it walks
through it. In fact I have a cleanup patch for this (which gets rid of
the alias decl that is, in fact, another PCH workaround hack.
>
> I hope to get some continuous integration of libgccjit going at some
> point (but am focusing on finishing my stage 1 stuff right now, and am
> hacking round this for now).
>
> I wonder if it would be useful for debug builds to
> call toplev::finalize, so that cc1/cc1plus exercise these cleanup code
> paths and thus catch this kind of breakage much earlier.
I think we could do that for checking compilers.
It would also make it easier to check for memory leaks...
Honza
>
> Dave
>
