[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

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

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
This is interesting. Simply doing the following eliminates the ice.

diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..a9e538cc2a1 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -6544,8 +6544,6 @@ loop:
     default:
       gfc_error ("Unexpected %s statement in MODULE at %C",
                 gfc_ascii_statement (st));
-
-      error = true;
       reject_statement ();
       st = next_statement ();
       goto loop;

I discovered this studying other code that was rejecting statements and found
the following existing function:

/* Generic complaint about an out of order statement.  We also do
   whatever is necessary to clean up.  */

static void
unexpected_statement (gfc_statement st)
{
  gfc_error ("Unexpected %s statement at %C", gfc_ascii_statement (st));

  reject_statement ();
}

I tried it at the location of the patch just above and it worked. The error
message is generic but no ice.  In fact the only difference is setting
error=true.

With the generic error message there are a couple of existing test cases that
don't pass but these would be minor edits.

All this begs the question about why set error=true.  Right after this the code
on parse.cc has:

  /* Make sure not to free the namespace twice on error.  */
  if (!error)
    s->ns = gfc_current_ns;

Well, setting it true s->ns is not getting set at all. Meaning it is left
uninitialized.  The comment about freeing the namespace is also bogus here.
There is no freeing of anything in this chunk of code.