[cfe-commits] [RFC and PATCH] Fortran

[Hal Finkel]

On Thu, 3 May 2012 15:02:37 -0700
Richard Smith <richard at metafoo.co.uk> wrote:

> On Thu, May 3, 2012 at 1:55 PM, Hal Finkel <hfinkel at anl.gov> 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