[cfe-commits] [RFC and PATCH] Fortran

Carter, Jack 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.

Jack

----------------------------------------------------------------------

Message: 1
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"

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.

 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:
program foo
end 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.

Thanks again,
Hal

--
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_fortran_20120503.patch
Type: text/x-patch
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
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


End of cfe-commits Digest, Vol 59, Issue 52
*******************************************




More information about the cfe-commits mailing list