New modref/ipa_modref optimization passes

David Malcolm dmalcolm@redhat.com
Tue Sep 22 11:21:21 GMT 2020


On Tue, 2020-09-22 at 09:07 +0200, Jan Hubicka wrote:
> > > (gdb) p summaries
> > > $3 = (fast_function_summary<modref_summary*, va_gc> *) 0x0
> > > 
> > > I'm still investigating (but may have to call halt for the
> > > night), but
> > > this could be an underlying issue with the new passes; the jit
> > > testsuite runs with the equivalent of:
> > > 
> > > --param=ggc-min-expand=0 --param=ggc-min-heapsize=0
> > > 
> > > throughout to shake out GC issues (to do a full collection at
> > > each GC
> > > opportunity).
> > > 
> > > Was this code tested with the jit?  Do you see issues in cc1 if
> > > you set
> > > those params?  Anyone else seeing "random" crashes?
> > 
> > I suppose this happes when pass gets constructed but no summary is
> > computed.  Dos the NULL pointer guard here help?
> 
> Hi,
> I am currently in train and can not test the patch easilly, but this
> should help.  If you run the pass on empty input then the destruction
> happens with NULL summaries pointer.
> 
> My apologizes for that.
> Honza
> 
> diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> index af0b710333e..cd92b5a81d3 100644
> --- a/gcc/ipa-modref.c
> +++ b/gcc/ipa-modref.c
> @@ -769,7 +885,8 @@ class pass_modref : public gimple_opt_pass
>  
>      ~pass_modref ()
>        {
> -	ggc_delete (summaries);
> +	if (summaries)
> +	  ggc_delete (summaries);
>  	summaries = NULL;
>        }

Thanks; with that it survives the first in-process iteration, but then
dies inside the 3rd in-process iteration, on a different finalizer. 
I'm beginning to suspect a pre-existing bad interaction between
finalizers and jit which perhaps this patch has exposed.

I'll continue to investigate it.

Dave



More information about the Gcc-patches mailing list