This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What about PR 13257?


 Yes it makes sence, please do.

 No anyhow, isn't yacc/lex mainly LARL(1) parsers ? This might complicate things a bit, I think we eventually will have to rewrite the parser, but I am not sure lex/yacc is the way to go.

 I would say that some kind of customized NFA tailored to the needs of the backend would be much nicer.

 Also if you look at the mailinglist archive this question pops up at regular intervalls, however I think the consensus is mostly that it will have to wait until gfortran is up and running on all cylinders.

 just my humble opinion.

 / Lars Segerlund.



On Tue, 21 Sep 2004 18:29:15 +0200
Tobias Schlüter <tobias.schlueter@physik.uni-muenchen.de> wrote:

> Janne Blomqvist wrote:
> >>(I don't understand why resolve_dt would come into play here, but it's been a
> >>while since I looked at this bug and decided that it's not as simple as it
> >>seems, so I asume you're right)
> > 
> > 
> > You're correct, unfortunately. Fixing this bug entails recognizing
> > what is probably meant by the incorrect format and then generating
> > code for it. Changing the error to a warning is just a triviality
> > after that. :(
> > 
> 
> I was wondering the other day if it would make sense to rewrite the format
> parser in bison/yacc. The handcoded state automaton is awful to debug and a
> maintenance burden, as the same grammar is reproduced in the library. It
> should then be possible to use the same code in the library and the compiler
> for the parsing. Ideas? Takers?
> 
> > I will now return to my regular hiding hole.
> 
> Wow, nowadays they have internet everywhere.
> 
> - Tobi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]