https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520
--- Comment #9 from Casey Webster <casey.webster at gmail dot com> --- (In reply to Steve Kargl from comment #8) > On Tue, Jul 07, 2015 at 07:10:48PM +0000, casey.webster at gmail dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520 > > > > --- Comment #7 from Casey Webster <casey.webster at gmail dot com> --- > > (In reply to Steve Kargl from comment #6) > > > On Tue, Jul 07, 2015 at 05:23:17PM +0000, casey.webster at gmail dot com > > > wrote: > > > > > > > > Also, while I'll agree that "Unclassifiable statement" is better > > > > than "Invalid character in name", it would be nicer to see > > > > "Unbalanced parenthesis". > > > > > > > > > > I'm sorry that gfortran does not meet your needs. But, given > > > how gfortran's matchers work, I doubt that anyone will produce > > > a patch to do what you want. I could be wrong. Maybe someone > > > will take up the challenge. > > > > > > The patch I developed and committed specifically addresses a > > > problem where the error message and the locus to which it > > > pointed are simply wrong. In 'c = exp(+a))', the old error > > > message pointed to '+', which is a valid token in a valid > > > expression. > > > > Understood. In this case would it be proper to request the other bug I > > filed > > be un-marked as a duplicate of this one so this one can be resolved and the > > other can still be fodder for someone with enough spare time and desire to > > look > > into it? Thanks for your patch btw, I only complained here since my bug was > > duped to this one. > > > > Sure, you could re-open the bug, but I doubt any of the current > gfortran contributors will ever attempt to 'fix' the issue. The > problem lies in how gfortran matches statements. It attempts to > match a valid statement. If it fails, gfortran will queue an > error message, back-up to what it considers a known good state, > and then call another matcher. gfortran repeats this process > for a collection of matchers. Consider an implied do-loop > in a print statement: > > print *, (x(i), i = 1, 2) > > gfortran will first attempt to match a complex constant of the > form (x, y). This fails and an error is queued. Then a matcher > for implied-do is run. It successes and clears the error queue. > > Now, your problem is all matchers fail and the first error > (or last because I can't remember) is printed. Sometimes those > error messages are a little muddled. Thanks for the information. I'm looking into this and I see there is already a matcher written for balanced parens: gcc/gfortran/match.c:124 match_parens (void) which is only called from gfc_match_if() and gfc_match_do() in match.c and from match_attr_spec() in decl.c. When I get some free time I'll familiarize myself better with the matchers and decoding in parse.c and if I come up with something I'll reopen the duped bug and propose a patch.
