Thanks for the responses!
> I might be wrong (I'd love to be wrong here!) but I think this is a bit
> too ambitious
>
You might be right about it being too ambitious, it would certainly be
wise to aim for less. A more polished, but less broad product is definitely
better than a buggy standard compliant one, and I think that it would go
better with the general philosophy of GSoC. I will take this fact into
consideration for the revised proposal.
Also, in your proposal, it looks as though you're not writing tests
until> the end; tests need to be written as soon as the features are testable.
>
That's kind of true, but I actually planned on writing tests during
feature development, it's just that these tests wouldn't cover
everything
and should be expanded and tested fully towards the end of GSoC. I should
definitely mention that in my plan.
As for the tooling support, I guess that it wouldn't hurt to take the fact
that tools should be integrated with flang in the future into account
during the development. I will take a look on how clang and various tools
for it operate.
2013/4/22 Hal Finkel <hfinkel at anl.gov>
> ----- Original Message -----
> > From: "Dmitri Gribenko" <gribozavr at gmail.com>
> > To: "Alex L" <arphaman at gmail.com>
> > Cc: "LLVM Developers Mailing List" <llvmdev at
cs.uiuc.edu>
> > Sent: Monday, April 22, 2013 9:00:51 AM
> > Subject: Re: [LLVMdev] GSoC project questions.
> >
> > On Mon, Apr 22, 2013 at 4:30 PM, Alex L <arphaman at gmail.com>
wrote:
> > > Thanks for your support.
> > > I wrote my draft GSoC proposal, it can be viewed here -
> > > https://gist.github.com/hyp/5434845
> > > Please read it and tell me what you think. Any criticisms or
> > > suggestions are
> > > welcome!
> >
> > Hello Alex,
> >
> > > I plan to make flang a fully featured frontend which fully
supports
> > > Fortran 77
> >
> > I might be wrong (I'd love to be wrong here!) but I think this is
a
> > bit too ambitious. Given that you have to write tests *as you
> > implement the features*, handle corner cases (and one has to actually
> > discover corner cases from the standard, if one is not familiar with
> > Fortran) and produce diagnostics for invalid code, I don't think
it
> > is
> > possible to implement all of the frontend + codegen within 12 weeks.
>
> Alex, I agree with Dmitri, I think that the proposal sounds a little too
> ambitious. Maybe everything will go smoothly and you'll be able to
> accomplish everything that you'd like, but we should plan for less. I
favor
> identifying a useful subset (such as that needed for BLAS) and focusing on
> doing a really good job on that subset rather than trying to get full
> feature coverage. In my experience, coding tests and high-quality
> warning/error messages takes more time than coding the feature itself.
> Also, in your proposal, it looks as though you're not writing tests
until
> the end; tests need to be written as soon as the features are testable.
>
> Regarding motivation, I would also like to bring the same kind of
> "tooling" (analysis and transformation) support available in
Clang to
> Fortran. Not that this specifically impacts your project, but I think is an
> important part of the longer-term motivation for developing an LLVM Fortran
> frontend.
>
> I am glad that you're excited about working on this project!
>
> -Hal
>
> >
> > Dmitri
> >
> > --
> > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at
gmail.com>*/
> > _______________________________________________
> > 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/20130422/378e667d/attachment.html>