<div><font size="3" face="Times New Roman">
</font><font face="Calibri"><font size="3">Dear All,</font></font></div><div><font size="3" face="Times New Roman">
</font></div><p style="margin:0in 0in 0pt" class="MsoNormal"><font face="Calibri"><font size="3">Thanks for your positive replays. I really value all your
inputs so far. Any product engineering in general can be successful only
through collective effort from right minded and skilled people and co-operation
among them. And, that is why the projects under LLVM compiler infrastructure
are very successful till date.</font></font></p><p style="margin:0in 0in 0pt" class="MsoNormal"><font size="3" face="Times New Roman"></font> </p><p style="margin:0in 0in 0pt" class="MsoNormal"><font size="3" face="Calibri">I have not taken in-depth look into </font><a href="https://github.com/isanbard/flang/"><font color="#0000ff" size="3" face="Calibri">https://github.com/isanbard/flang/</font></a><font face="Calibri"><font size="3">.
Will plan to spend some time going through it. </font></font></p><p style="margin:0in 0in 0pt" class="MsoNormal"><font face="Calibri"><font size="3"></font></font> </p><p style="margin:0in 0in 0pt" class="MsoNormal"><font face="Calibri"><font size="3">More ever, I belong to a
semi-conductor company, where we are currently in need of a latest standard
compliant, LLVM targeted FORTRAN compiler, with backward compatibility to older
standards too. We are currently debating all possible options as it usually
happens in all companies within the framework of their business models. </font></font></p><p style="margin:0in 0in 0pt" class="MsoNormal"><font size="3" face="Times New Roman"></font> </p><p style="margin:0in 0in 0pt" class="MsoNormal">
<font face="Calibri"><font size="3">So, please give me some time. I will get back to you on this
topic. If it works out well, we all of us put our collective efforts together
and make this project a reality and serves the need of different people like
industry people, academicians, researchers, etc.</font></font></p><div><font size="3" face="Times New Roman">
</font></div><div><font size="3" face="Times New Roman">--</font><br>mahesha</div><div><br> </div><div class="gmail_quote">On Sat, Aug 25, 2012 at 12:37 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div class="HOEnZb"><div class="h5">On Sat, 25 Aug 2012 13:52:13 +0700<br>
"C. Bergström" <<a href="mailto:cbergstrom@pathscale.com">cbergstrom@pathscale.com</a>> wrote:<br>
<br>
> On 08/25/12 01:05 PM, Hal Finkel wrote:<br>
> > On Fri, 24 Aug 2012 17:40:07 -0700<br>
> > John McCall<<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br>
> ><br>
> >> A high-quality LLVM-backed FORTRAN frontend would be great.<br>
> > I strongly agree (and I'd like to work on this as well). I started a<br>
> > discussion about this a few months ago, see:<br>
> > <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120430/057199.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120430/057199.html</a><br>
> ><br>
> >> I do not<br>
> >> think it'd be a good idea in the long run to implement it by<br>
> >> translating FORTRAN into Clang's C ASTs, and there are probably<br>
> >> relatively few things that you could re-use from Clang's source<br>
> >> code. I recommend using Clang primarily as a design model, rather<br>
> >> than as a shortcut to a working implementation.<br>
> > I think that there are a few things that can be shared, the two<br>
> > largest pieces are probably:<br>
> ><br>
> > - The driver (both C and family and Fortran share many of the same<br>
> > requirements for finding basic system libraries and tools and<br>
> > running them)<br>
> ><br>
> > - The C preprocessor (any production Fortran compiler needs a C<br>
> > preprocessor (with slightly-modified tokenization rules). With<br>
> > some refactoring, this should also be shared.<br>
> ><br>
> >> If you're seriously interested in this, there are ways that we<br>
> >> could suggest to *improve* on Clang as an implementation model. In<br>
> >> particular, I would recommend introducing a third IR, so that the<br>
> >> translation goes like so: source code -> AST -> high-level IR<br>
> >> -> LLVM IR -> machine code<br>
> > Do you view this high-level IR as being C-ish in scope (with better<br>
> > aliasing rules)? For example, do you think that array slices will be<br>
> > expanded at this high-level IR, or would that wait until CodeGen?<br>
> * I'm willing to *pay* someone to work on the parsing and sema<br>
> aspects of this. We (PathScale) however require support for F90, 95,<br>
> 2003 and 2008 though. So while "modern" Fortran may have a lot of<br>
> the same OO design principles there's still some legacy involved with<br>
> the older standards. (Anyone thinking they don't have to support<br>
> F95+ is kidding themselves - there's just too much legacy code out<br>
> there if you want it to actually be used)<br>
<br>
</div></div>There is a bunch of Fortran 77 out there too ;)<br>
<div class="im"><br>
><br>
> * Have you looked or considered contributing to Bill's work?<br>
> <a href="https://github.com/isanbard/flang/" target="_blank">https://github.com/isanbard/flang/</a><br>
<br>
</div>I think that this is a good start, but the highest-productivity<br>
solution will require a greater reuse of clang components (driver,<br>
preprocessor, etc.).<br>
<div class="im"><br>
><br>
> * I fully agree with John that a higher level IR is necessary, but I<br>
> view AST->IR generation to be a separate project in itself. Thinking<br>
> of the high-level IR as C-ish is fundamentally flawed.<br>
<br>
</div>I wouldn't go that far ;) -- at some point the array slicing semantics<br>
need to be lowered into explicit allocations, loops, etc. and so my<br>
question is, specifically, where does that happen. Regardless, I<br>
certainly agree that we'll want higher-level transformations prior to<br>
that lowering.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Hal<br>
</font></span><div class="im HOEnZb"><br>
> Fortran<br>
> treats arrays as 1st class citizens and trying to code Fortran<br>
> C-style is just wrong. (imho)<br>
><br>
> For anyone interested in working on sema/parsing - I have private<br>
> testsuites which extensively cover the various Fortran standards.<br>
> ping me offlist to coordinate.<br>
><br>
> Best,<br>
><br>
> ./C<br>
><br>
<br>
<br>
<br>
</div><div class="im HOEnZb">--<br>
Hal Finkel<br>
Postdoctoral Appointee<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>mahesha</div><br>