[cfe-commits] [RFC and PATCH] Fortran

Matthieu Monrocq matthieu.monrocq at gmail.com
Fri May 4 10:21:03 PDT 2012


On Fri, May 4, 2012 at 7:14 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On May 4, 2012, at 4:27 AM, Hal Finkel wrote:
>
> >>
> >> FWIW, I don't think that this makes sense from a community standpoint.
> >>
> >> If you're serious about building a fortran frontend (which would be
> >> really really cool).  I think we should start it as another LLVM
> >> subproject.  It can certainly build off and use the Clang "liblex" to
> >> get the preprocessor etc, and taking changes to support Fortran into
> >> the clang tree would be perfectly fine.
> >
> > Alright cool, let's do that then. Based on the feedback I've received,
> > it seems like it makes the most sense to add Fortran support directly
> > into the driver and lexer, and keep everything else as a separate
> > subproject. This subproject will have its own Parser, Sema, AST,
> > CodeGen, etc. subdirectories.
>
> Sounds good to me.
>
> > If we set this up kind of like clang is
> > setup, then the build system will detect whether there is a fortran
> > subdirectory in clang, and if so, will build (defining
> > CLANG_HAS_FORTRAN or something like that) and link the extra components.
>
> Should "flang" (please come up with a better name! :) be in
> llvm/tools/flang or in llvm/tools/clang/flang?  I think that the former
> makes more sense.  These are peer projects, even if one is dependent on the
> other.
>
> -Chris
>


One minor nit: I can certainly understand reusing the lexer/preprocessor if
it is nearly identical and the tooling mechanism just added by Manuel
because it's a great infrastructure, however on the other hand I am not
sure about the driver itself...

I don't know Fortran, so perhaps it's obvious to you Hal, but I wonder if
perhaps it would make sense to produce a different binary, with its own set
of flags ?

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120504/624cedcc/attachment.html>


More information about the cfe-commits mailing list