This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran] Fix PR 16161
- From: Steven Bosscher <stevenb at suse dot de>
- To: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>,GCC Fortran mailing list <fortran at gcc dot gnu dot org>,patch <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 30 Jun 2004 00:23:50 +0200
- Subject: Re: [gfortran] Fix PR 16161
- Organization: SUSE Labs
- References: <40E1D6F4.1060209@physik.uni-muenchen.de>
On Tuesday 29 June 2004 22:54, Tobias Schlüter wrote:
> PR 16161 deals with a funny bug in our matchers:
> IMPLICIT CHARACTER (c); END
> would yield a syntax error, because (c) would be recognized as a
> character length, and this would in turn mess up parsing. This patch
> fixes this by making gfc_match_typespec not deal with character legths
> when parsing the implicit statement.
It's interesting to see how our "greedy" template matcher works sometimes.
I wish we'd try to parse one token at a time and gradually move to a more
traditional recursive-descent-like parser with backtracking. Oh well...
> Since I now had to call
> match_char_spec from gfc_match_implicit, I changed the distribution of
> the functions to files somewhat: I moved gfc_match_implicit to decl.c
> and also moved gfc_match_implicit_none to keep those functions together.
> After this, gfc_match_type_spec could become a static function.
That does make the patch a bit harder to review ;-)
> Compiled and tested on i686-pc-linux. I will add the testcase from the
> PR to the compile testsuite.
This is OK
Note...
+ if (c != '(')
+ {
+ gfc_error ("Missing character range in IMPLICIT at %C");
+ goto bad;
+ }
+bad:
+ gfc_syntax_error (ST_IMPLICIT);
+
+ gfc_current_locus = cur_loc;
+ return MATCH_ERROR;
+}
we really shouldn't issue two error messages for the same error here.
Gr.
Steven