[cfe-commits] [RFC and PATCH] Fortran
jcarter at mips.com
Thu May 3 14:01:08 PDT 2012
This seems like a natural progression. The SGI compiler that morphed into the Pro64 handled modern fortran as well as c++ and c.
Fortran is still the go to language for scientific number crunching. It will push llvm optimization for the good.
Date: Thu, 3 May 2012 15:55:18 -0500
From: Hal Finkel <hfinkel at anl.gov>
Subject: [cfe-commits] [RFC and PATCH] Fortran
To: cfe-commits at cs.uiuc.edu
Message-ID: <20120503155518.3e5caa63 at sapling2>
Content-Type: text/plain; charset="us-ascii"
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
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.
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. In doing so, we can even reuse a lot of
the semantic-analysis code. I think that this can be done is a clean
way while disturbing very little of the C/C++ code (and reusing large
chunks of it).
I would like to propose the attached patch, after some test cases are
added, for inclusion into clang. This patch contains what I believe to
be nearly complete modifications to the dirver and lexer. It also
contains a stub parser -- it is capable of compiling only the simplest
possible do-nothing free-form Fortran program:
Perhaps we would like a more-complete implementation prior to
considering this for trunk integration, but as incremental patches may
be preferable, I figured that I'd try to start a discussion about this
earlier rather than later (and, hopefully, attract some collaborators).
Please let me know what you think.
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 66842 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-commits/attachments/20120503/09e0b29d/attachment.bin
cfe-commits mailing list
cfe-commits at cs.uiuc.edu
End of cfe-commits Digest, Vol 59, Issue 52
More information about the cfe-commits