[LLVMdev] GSoC project questions.

[Alex L]

>
> No. I think that you might want to use Clang for inspiration on design,
> but you'd certainly not be bound to that. If you'd like to take a much more
> start-from-scratch approach, you can also look at the code that Bill put
> together: https://github.com/isanbard/flang - If you use that as a base,
> we can always merge it with the useful lfort pieces later.

Ok, that's good to know. In the next couple of days I will study the lfort
repository more, and see if I can perhaps contribute a commit or two.
Thankfully I know git and github and so that would make lfort really
accessible for me.


2013/4/13 Hal Finkel <hfinkel at anl.gov>

> ----- Original Message -----
> > From: "Alex L" <arphaman at gmail.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, "Bill Wendling" <
> isanbard at gmail.com>, "LLVM Developers Mailing
> > List" <llvmdev at cs.uiuc.edu>
> > Sent: Saturday, April 13, 2013 11:34:43 AM
> > Subject: Re: [LLVMdev] GSoC project questions.
> >
> >
> > Thanks for your replies.
> > Working on the lfort compiler would certainly be an interesting
> > project for me for this GSoC.
>
> Great!
>
> > I have studied lfort repository and
> > commits, and I see that it has a lot of stuff for C/C++, am I
> > correct that this is a fork of Clang? If this is correct, I wonder
> > why this approach was chosen instead of starting out from scratch -
> > is it because Clang already has a lot of code which can be reused
> > for the Fortran compiler?
>
> Yes, lfort started out as a fork of Clang, but I don't think that is
> overly relevant at this point. There are a few things from Clang that the
> Fortran compiler could really reuse:
>
>  1. The driver/tools infrastructure (the code that finds the system
> libraries, knows how to call the assembler, linker, etc.)
>  2. The C preprocessor (in practice, a lot of Fortran code assumes the
> existence of an integrated C preprocessor).
>    2a. The lexical analysis framework, and to some extent, the classes for
> printing nice error messages
>  3. The directory layout and regression-testing setup
>
> At this point, I've pretty much finished taking advantage of all of those
> pieces in lfort, and the remainder of the core code from Clang needs to be
> replaced with Fortran-specific bits. Keeping the same general design
> probably makes sense, but I could certainly be convinced otherwise.
>
> > I'm also unfamiliar with Clang and I was a
> > bit overwhelmed when I saw the lfort repository at first because of
> > this. If I were to work on this project, would I be required to use
> > the Clang code?
>
> No. I think that you might want to use Clang for inspiration on design,
> but you'd certainly not be bound to that. If you'd like to take a much more
> start-from-scratch approach, you can also look at the code that Bill put
> together: https://github.com/isanbard/flang - If you use that as a base,
> we can always merge it with the useful lfort pieces later.
>
> Thanks again,
> Hal
>
> >
> >
> >
> > 2013/4/13 Hal Finkel < hfinkel at anl.gov >
> >
> >
> >
> > ----- Original Message -----
> > > From: "Anton Korobeynikov" < anton at korobeynikov.info >
> >
> > > To: "James Courtier-Dutton" < james.dutton at gmail.com >
> > > Cc: "Hal Finkel" < hfinkel at anl.gov >, "Bill Wendling" <
> > > isanbard at gmail.com >, "LLVM Developers Mailing List"
> > > < llvmdev at cs.uiuc.edu >
> >
> > > Sent: Saturday, April 13, 2013 9:12:39 AM
> > > Subject: Re: [LLVMdev] GSoC project questions.
> > >
> >
> > > > I agree that creating a complete Fortran compiler is a huge
> > > > effort.
> > > > But what about approaching it from a test driven development
> > > > perspective?
> > > > We start with a few small Fortran programs as "test cases".
> > > > The GSoC task then gives the task as getting test case 1 to work.
> > > > We could also apply this of "lfort". Determine a test case that
> > > > currently
> > > > fails on lfort, and ask the GSoC task to pass the test.
> > > All this make sense only if there is interested party in long-term
> > > development and maintenance. Otherwise the code will bitrot really
> > > quickly and thus will be waste of time and money. Is there such a
> > > party?
> >
> > I am certainly interested in long-term development and maintenance. I
> > think that the first step toward making a useful Fortran compiler is
> > this:
> >
> > 1. It should be able to compile BLAS: http://www.netlib.org/blas/
> > (these are Fortran 77, and have no I/O, so should be relatively
> > simple)
> >
> > 2. If that is complete, then move on to LAPACK:
> > http://www.netlib.org/lapack/index.html (these use some subset of
> > Fortran 90)
> >
> > As you can see from the test cases currently in lfort, most of the
> > driver functionality and lexical analysis (for both Fortran 77 and
> > 90) is done, and I've started on parsing (and semantic analysis and
> > codegen for) variable declarations and some simple statements. I
> > think that a motivated student could make a lot of headway, and
> > should be able to at least finish step 1. Thoughts?
> >
> > -Hal
> >
> >
> >
> > >
> > > --
> > > With best regards, Anton Korobeynikov
> > > Faculty of Mathematics and Mechanics, Saint Petersburg State
> > > University
> > >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130413/6332dc3f/attachment.html>