This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Will tree-ssa be GCC 3.5?


Steven Bosscher wrote:

(The available Fortran front end is of course the excelent Cray Fortran 90 front end which is a fine piece of software with a GPL v2.0 license and an SGI copyright, hence "not free enough" for the FSF, but "free enough" for everybody else.)

Don't make this assumption. If there are good arguments for including this front end in the gcc project, then the copyright issue is discussable (both with SGI and FSF).


P.S. I am not sure what you mean by available here, but there are certainly other Fortran front ends around, e.g. from IBM.

You are very misguided here :-) Fortran is an _insane_ language. Writing a Fortran front end is probably the hardest part of writing a Fortran compiler, especially for Fortran 77, but also for more recent dialects.

Come on, it's not that complex


First of all, Fortran does not have a proper grammar (not LL, not LR, and not even GLR apparently).

Well no language has an LR grammar, you can only generate an LR grammar for a superset of any language. So it is just a matter of choosing the superset appropriately.


Second, it does not have reserved keywords, so your parser and scanner end up interacting all the time and disambiguating keywords/identifiers/operators is sometimes difficult.

This is really not a significant difficulty


Third, you need to read ahead whole statements even before you can lex/parse them. Finally, Fortran doesn't know all symbols while parsing because they don't have to be predeclared.

So what? These simply are not significant issues. Compiling Fortran efficiently is hard, but these are not the hard problems.


Hence, typical Fortran "parsers" have in fact four tightly coupled passes: prelexing, lexing, parsing and name/type resolution. Fun, I assure you.

Again, I think you are greatly exaggerating the difficulty.


Later Fortran dialects have constructs for which efficient code generation is non-obvious and poorly described in the literature, but as you say, that's in the middle end.

Efficient code generation is not "obvious" in any language. Yes, there are tough optimization problems in Fortran, but that's true in other languages too.


But of course, this is even more off-topic than the rest of this thread :-)

Indeed, but it is hard not to respond to misinformation :-) :-)




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