[cfe-dev] Need for new FORTRAN front-end for LLVM ?

["C. Bergström"]

On 08/25/12 01:05 PM, Hal Finkel wrote:
> On Fri, 24 Aug 2012 17:40:07 -0700
> John McCall<rjmccall at apple.com>  wrote:
>
>> A high-quality LLVM-backed FORTRAN frontend would be great.
> I strongly agree (and I'd like to work on this as well). I started a
> discussion about this a few months ago, see:
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120430/057199.html
>
>>   I do not
>> think it'd be a good idea in the long run to implement it by
>> translating FORTRAN into Clang's C ASTs, and there are probably
>> relatively few things that you could re-use from Clang's source
>> code.  I recommend using Clang primarily as a design model, rather
>> than as a shortcut to a working implementation.
> I think that there are a few things that can be shared, the two largest
> pieces are probably:
>
>   - The driver (both C and family and Fortran share many of the same
>     requirements for finding basic system libraries and tools and
>     running them)
>
>   - The C preprocessor (any production Fortran compiler needs a C
>     preprocessor (with slightly-modified tokenization rules). With some
>     refactoring, this should also be shared.
>
>> If you're seriously interested in this, there are ways that we could
>> suggest to *improve* on Clang as an implementation model.  In
>> particular, I would recommend introducing a third IR, so that the
>> translation goes like so: source code ->  AST ->  high-level IR ->  LLVM
>> IR ->  machine code
> Do you view this high-level IR as being C-ish in scope (with better
> aliasing rules)? For example, do you think that array slices will be
> expanded at this high-level IR, or would that wait until CodeGen?
* I'm willing to *pay* someone to work on the parsing and sema aspects 
of this.  We (PathScale) however require support for F90, 95, 2003 and 
2008 though.  So while "modern" Fortran may have a lot of the same OO 
design principles there's still some legacy involved with the older 
standards.  (Anyone thinking they don't have to support F95+ is kidding 
themselves - there's just too much legacy code out there if you want it 
to actually be used)

* Have you looked or considered contributing to Bill's work?
https://github.com/isanbard/flang/

* I fully agree with John that a higher level IR is necessary, but I 
view AST->IR generation to be a separate project in itself.  Thinking of 
the high-level IR as C-ish is fundamentally flawed.  Fortran treats 
arrays as 1st class citizens and trying to code Fortran C-style is just 
wrong. (imho)

For anyone interested in working on sema/parsing - I have private 
testsuites which extensively cover the various Fortran standards.  ping 
me offlist to coordinate.

Best,

./C