On Thu, 3 May 2012 15:02:37 -0700 Richard Smith <[email protected]> wrote:
> On Thu, May 3, 2012 at 1:55 PM, Hal Finkel <[email protected]> wrote: > > > Hello, > > > > In order to support our users who have Fortran codes, I would like > > to start working on adding Fortran support into clang. While at > > first this may seem like an odd fit, I think that it should work > > well for two reasons: > > > > 1. Most modern Fortran codes actually rely on the C preprocessor, > > and so almost all Fortran compilers provide some kind of > > "integrated" C preprocessor (often with some slightly different > > main-source tokenization rules). For those of you who are not > > familiar, the convention is that .f, .f90, etc. are plain Fortran > > files while .F, .F90, etc. require the C preprocessor. clang has a > > good preprocessor implementation, a lot of machinery for dealing > > with parsing on top of the preprocssor and providing good errors and > > warnings in the presence of macros. Reusing clang's capabilites > > here makes a lot of sense. > > > > I think this idea may have some merit. A 'Fortran preprocessor' mode > for the Clang preprocessor doesn't seem like an inherently bad idea, > so long as it doesn't get in the way of performance or maintenance of > the preprocessor as it is used by the C frontend. Thanks! The patch provided does exactly this (by adding a Fortran mode to the Preprocessor/Lexer). I tried to make any fast-path changes as minimal as I could. > > > > 2. Modern Fortran is actually very similar to C++. It provides > > modules (which are very much like C++ namespaces), types (which are > > very much like C++ classes), operator overloading, etc. The > > control-flow structures and built-in types are very similar between > > the two languages; almost all of the differences are syntactical. > > As a practical matter, Fortran is the "other" high-performance > > language. It would make a lot of sense to reuse the AST->LLVM code > > in clang, as much of it will be identical for Fortran. > > > > My idea is to modify the Lexer to support Fortran tokenization, and > > create a Fortran parser. This parser will, for the most part, map > > the Fortran code onto the C++ AST. > > > This is very much in conflict with the design goals of Clang. We go to > great pains to exactly represent the form of the code in the AST, and > using the existing nodes to represent Fortran would really not fit. Fair enough, I can certainly design a set of Fortran AST nodes inspired by the ones used for C++. The only disadvantage to this, if it is a disadvantage at all, is that proper code reuse will then require additional refactoring in CodeGen. > > > > In doing so, we can even reuse a lot of > > the semantic-analysis code. > > > I would be very surprised if that's true. Not knowing Fortran myself, > I've taken a look through the standard, and none of it seems > particularly similar to the rules of C++. Certainly not similar > enough that the C++ rules would provide the same results. And reusing > the C++ semantic analysis would mean producing the C++ diagnostics, > which would be entirely inappropriate. > > > > Please let me know what you think. > > > > I think a Fortran frontend would be great to have in LLVM. If you > intend to produce a high-quality frontend (one which to Fortran is as > Clang is to C and C++), then I think any attempt to share Clang's > parser, AST or semantic analysis would be to the detriment of your > project (and to Clang). However, following the structure of Clang, > and even drawing inspiration from its representation of types, > expressions, etc., seems like a sensible approach. This makes a lot of sense; I can certainly proceed along those lines. Sincerely, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
