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).
[...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"?
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.
Dave
