[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

["pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #6)
> (In reply to Mikael Morin from comment #5)
> > Possibly walking the symbols in reverse order to release them would fix this.
> > 
> It seems to work:
> 
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 37a9e8fa0ae..4a71d84b3fe 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -3661,7 +3661,7 @@ gfc_restore_last_undo_checkpoint (void)
>    gfc_symbol *p;
>    unsigned i;
>  
> -  FOR_EACH_VEC_ELT (latest_undo_chgset->syms, i, p)
> +  FOR_EACH_VEC_ELT_REVERSE (latest_undo_chgset->syms, i, p)
>      {
>        /* Symbol in a common block was new. Or was old and just put in
> common */
>        if (p->common_block

So does this:

diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 37a9e8fa0ae..ada8cb2ba83 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3703,6 +3703,10 @@ gfc_restore_last_undo_checkpoint (void)
            }
          p->common_next = NULL;
        }
+
+      if (!strlen(p->name))
+       continue;
+
       if (p->gfc_new)
        {
          /* The derived type is saved in the symtree with the first

I think that yours is likely to be better though. Have you understood why the
symbol order matters in this case?

BTW pr99798 is another ref counting ICE; this time involving namespaces.

Paul