This is the mail archive of the
mailing list for the GCC project.
[Bug fortran/27954] ICE on garbage in DATA statement
- From: "pault at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Oct 2006 09:20:02 -0000
- Subject: [Bug fortran/27954] ICE on garbage in DATA statement
- References: <email@example.com/bugzilla/>
- Reply-to: 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
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.
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:
*** gcc/fortran/decl.c (révision 117879)
--- gcc/fortran/decl.c (copie de travail)
*** 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;
current_as = NULL;
This is not checked for breakages or regtested but I believe that it is the
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.)
pault at gcc dot gnu dot org changed:
What |Removed |Added
CC| |jvdelisle at gcc dot gnu dot