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 <[email protected]> Subject: [cfe-commits] [RFC and PATCH] Fortran To: [email protected] Message-ID: <20120503155518.3e5caa63@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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits End of cfe-commits Digest, Vol 59, Issue 52 ******************************************* _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
