[Bug fortran/27954] ICE on garbage in DATA statement

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

------- Comment #16 from pault at gcc dot gnu dot org  2006-10-20 09:20 -------
The problem is specific to old-style initializers, as 
program FOO
  real :: x = 2.0 q
  real z /2.0/ q
end program FOO
shows (comment out each declaration in turn!).

Grepping on the first error message leads us to decl.c(gfc_match_data_decl).

Proceeding to the Doxygen documentation, we find right away that there is
nothing in the loop over variables that would distinguish old-style data, so
this must happen in variable_decl.

eh voila!
01186       return match_old_style_init (name);

In this function, we find that the gfc_data, it produces, contains an
expression that points to the symtree for the variable. In ALL OTHER error
routes, this gfc_data is freed so that the hanging pointer to the symtree and
to the soon to be non-existent symbol is removed.

match_old_style_init returns SUCCESS and so has hung the gfc_data entry onto
gfc_current_ns->data where it remains until the compiler splutters its last on
trying to swallow it.

Once we figure that, we know right away that this fixes the problem:
Index: gcc/fortran/decl.c
===================================================================
*** gcc/fortran/decl.c  (révision 117879)
--- gcc/fortran/decl.c  (copie de travail)
*************** ok:
*** 2368,2373 ****
--- 2368,2384 ----
    gfc_error ("Syntax error in data declaration at %C");
    m = MATCH_ERROR;

+   /* Check if there are any old fashioned data statements around.
+      If there are, they risk leaving dangling symtree references
+      and do nothing for us since an error has occurred.  */
+   for (;gfc_current_ns->data;)
+     {
+       gfc_data *d;
+       d = gfc_current_ns->data->next;
+       gfc_free (gfc_current_ns->data);
+       gfc_current_ns->data =d;
+     }
+
  cleanup:
    gfc_free_array_spec (current_as);
    current_as = NULL;

This is not checked for breakages or regtested but I believe that it is the
right solution.

It does not fix PR18923 but I think that something similar is at play and could
be investigated in the same way.

(Jerry, I am preparing to depart on a trip; I would be happy if you would
finish off the development of this patch because I cannot return to it for at
least a week.)

Regards

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954