Fwd: Re: [Patch, fortran] PR69498 Fix ICE on unexpected submodule

Fwd: Re: [Patch, fortran] PR69498 Fix ICE on unexpected submodule

[Nicolas Koenig]

Hello Dominique,

as far as I understand this bug it has little to do with the SUBMODULE 
being in the wrong place (the subject of this mail was a bit 
misleading). The problem is that after calling 
gfc_restore_last_undo_checkpoint() it doesn't clean the symtree properly 
if there is a SUBMODULE statement, because it calls gfc_delete_symtree() 
with the name of the symbol whose symtree node should be deleted. But 
there no longer is a symtree node with the same name as the symbol, 
since the symbol has been renamed in module.c:794(gfc_match_submodule) 
from 'submod' to 'mod.submod'. This leaves the symtree with a node that 
points to a released symbol. I think the best way to ensure that this 
node is deleted is just to ignore everything before the dot in 
gfc_delete_symtree() as in the suggested patch, but there might be far 
better ways.

Nicolas

P.S.: The case only crashes because the compiler later creates a new 
symbol at the exact same place as the submodule symbol. It then proceeds 
to crash because the refs count no longer matches. Made debugging fun :D

On 03/26/2017 01:44 PM, Dominique d'Humières wrote:
> Dear Nicolas,
>
> A long time ago Paul sent me the following patch that fixes all three submodule ICEs in pr69498
>
> Index: gcc/fortran/module.c
> ===================================================================
> *** gcc/fortran/module.c	(revision 236994)
> --- gcc/fortran/module.c	(working copy)
> *************** gfc_match_submodule (void)
> *** 744,749 ****
> --- 744,756 ----
>      if (!gfc_notify_std (GFC_STD_F2008, "SUBMODULE declaration at %C"))
>        return MATCH_ERROR;
>    
> +   if (gfc_current_state () != COMP_NONE)
> +     {
> +       gfc_error ("SUBMODULE declaration at %C cannot appear within "
> + 		 "another scoping unit");
> +       return MATCH_ERROR;
> +     }
> +
>      gfc_new_block = NULL;
>      gcc_assert (module_list == NULL);
>    
> Cheers,
>
> Dominique
>

Re: Fwd: Re: [Patch, fortran] PR69498 Fix ICE on unexpected submodule

[Thomas Koenig]

Hi Nicolas,

> as far as I understand this bug it has little to do with the SUBMODULE
> being in the wrong place (the subject of this mail was a bit
> misleading). The problem is that after calling
> gfc_restore_last_undo_checkpoint() it doesn't clean the symtree properly
> if there is a SUBMODULE statement, because it calls gfc_delete_symtree()
> with the name of the symbol whose symtree node should be deleted. But
> there no longer is a symtree node with the same name as the symbol,
> since the symbol has been renamed in module.c:794(gfc_match_submodule)
> from 'submod' to 'mod.submod'. This leaves the symtree with a node that
> points to a released symbol. I think the best way to ensure that this
> node is deleted is just to ignore everything before the dot in
> gfc_delete_symtree() as in the suggested patch, but there might be far
> better ways.
>
> Nicolas
>
> P.S.: The case only crashes because the compiler later creates a new
> symbol at the exact same place as the submodule symbol. It then proceeds
> to crash because the refs count no longer matches. Made debugging fun :D

The patch is OK, unless somebody objects in the next day or so.

Regards

	Thomas