------- Comment #6 from pault at gcc dot gnu dot org 2006-09-14 20:05 -------
Iguchi-san and Tobi,
This has proven to be an "absorbing" bug and is indicative of a rather serious
malaise in the gfortran parser. As I surmised in the previous comment, it is
the assignments that are the culprits. In fact, these are being matched in
compiler states where an assignment should not be present; eg. in the
specification part of a module, an interface or the contains part.
I am just now regtesting a trial:
parse.c:127
/* Match statements whose error messages are meant to be overwritten
by something better. */
if (gfc_current_state () != COMP_INTERFACE
&& gfc_current_state () != COMP_MODULE
&& gfc_current_state () != COMP_CONTAINS)
{
match (NULL, gfc_match_assignment, ST_ASSIGNMENT);
match (NULL, gfc_match_pointer_assignment, ST_POINTER_ASSIGNMENT);
match (NULL, gfc_match_st_function, ST_STATEMENT_FUNCTION);
}
This regtests OK on trunk.
I am not suggesting that this is the fix but it is indicative of the right way
to go, I think.
Paul
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tobi at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2006-09-13 16:06:29 |2006-09-14 20:05:51
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
