[LLVMdev] [GSoC] Flang's end of GSoC report

[Alex L]

Thanks everyone!

I think that by reusing clang's code flang will benefit a lot. Clang's type
system and declaration nodes will be especially useful because of CAF. And,
of course, clang's tool interfaces, frontend and driver will come in handy.
But at the same time Fortran isn't C, so I don't expect that clang will
incorporate any features from flang or accommodate any needs that flang
might have. But perhaps clang could be made more flexible so that it would
encourage other frontends to reuse its valuable infrastructure. I don't
really have any ideas or suggestions how that can be done at the moment,
but I hope that somebody else might.

Cheers,
Alex


2013/9/24 Hal Finkel <hfinkel at anl.gov>

> ----- Original Message -----
> > On Tue, Sep 24, 2013 at 12:01:46AM +0700, "C. Bergström" wrote:
> > > On 09/23/13 11:54 PM, Chris Lattner wrote:
> > > >
> > > >On Sep 23, 2013, at 5:25 AM, Alex L <arphaman at gmail.com
> > > ><mailto:arphaman at gmail.com>> wrote:
> > > >
> > > >>Hi everyone!
> > > >>
> > > >>Today is the official "pencils down" day for GSoC and I wrote a
> > > >>report describing what results I've achieved since my last
> > > >>report in July:
> > > >>
> > > >>http://flang-gsoc.blogspot.ie/2013/09/end-of-gsoc-report.html
> > > >>
> > > >>Thanks for this GSoC LLVM!
> > > >
> > > >Wow, this is really fantastic work.  I'm surprised and impressed
> > > >by how much progress you made.
> > > >
> > > >Can you comment more about Pathscale's plans, and why they don't
> > > >want to release the code?
> > > Initially the code will continue to be developed privately, but
> > > there's a big ?<question mark> and sticky note to look at what
> > > makes
> > > best sense - It's a conservative approach, but that's how it is for
> > > now.
> >
> > Given the nature of path64, I think it would be nice to keep all
> > parsing
> > related parts and all semantic analysis open. It would also be nice
> > to
> > keep functional tests for the code generation as open as possible,
> > even
> > if might not fit into a "main" repository due to testing executable
> > code. The goal would be to allow Pathscale to what they are doing on
> > the
> > backend without having a strongly divergating frontend, which is
> > likely
> > not in the interest of anyone.
> >
> > I am aware that flang in the current form shared code with clang in
> > non-trivial ways and it certainly will require some effort to
> > refactor
> > the code on either side for allowing flang to become an integrated
> > LLVM
> > project. Who's interested with dealing with that on the Clang side? I
> > hope Alex is willing to work on the flang side?
>
> Alex may be otherwise captured for the time being, but I plan on working
> on this over the next few months. As I've mentioned in the past, I'd like
> the two projects to share the driver (or at least the driver
> infrastructure), and I'd like to give flang a C preprocessor based on
> Clang's. Regarding other code sharing, we'll need to do some serious
> thinking about what parts should actually be shared in the long run vs.
> what's acting as a crutch right now.
>
>  -Hal
>
> >
> > Joerg
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> 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/20130924/6381c923/attachment.html>