----- 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 > >
> > 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>
Hi again, I was studying and building the lfort repository as I said I would do, but after a while I decided that I would like to work on flang instead. So, I forked flang and so far I've had pretty good success with it, here's what I've done: - Merged a pull request from a github user Michael Gottesman(He added support for latest llvm and cmake) - Fixed character literal continuation bug. - Implemented INCLUDE statement (Only searches for files in -I dirs now) - Implemented if-stmt(not the full if-construct yet). You can see my repository here: https://github.com/hyp/flang So far I've enjoyed working on flang, and I would like to apply to GSoC with it. I will start writing a proposal in the next couple of days. Should I send it to the mailing list first, or should I send it directly to GSoC? Thanks. 2013/4/13 Alex L <arphaman at gmail.com>> 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/20130419/fc90ef37/attachment.html>