<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 6:26 PM Fangrui Song via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 2020-01-13, Renato Golin via llvm-dev wrote:<br>
>On Mon, 13 Jan 2020 at 06:50, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
>> I don't really consider this addressed without a plan of action (before merge) that contains a list of standard llvm support libraries that would be used in addition to things being removed (pretty much all use of C++ c* headers and more?) as well as staffing and approximate ETAs.<br>
><br>
>Agreed.<br>
><br>
>> I think waiting until after the llvm 10 branch would probably be best at this point. That will give a lot of time for cleanup and to make f18 a much more reasonable "preview" including code generation in a forthcoming release in about 6 mos.<br>
><br>
>Before this thread, I thought the progress of F18 was much further<br>
>than it is. My initial comments assumed it.<br>
><br>
>Now, I am surprised it's not using LLVM API yet (a clear and<br>
>consistent complaint of the previous one), as well as having its own<br>
>driver, test infra, etc.<br>
><br>
>The lack of C++ compatibility may look small now, but once we want to<br>
>move to a newer standard, Flang will be the bottleneck. In a monorepo,<br>
>these things are even more important.<br>
><br>
>F18 was supposed to be a whole new front-end, from scratch, but it<br>
>looks to have carried along many of the previous projects' flaws.<br>
><br>
>I really wouldn't like to see the next release with such wide range of<br>
>incompatibilities.<br>
><br>
>So, +1 to both waiting the release branch as well as a concrete plan<br>
>with a deadline to address all the critical issues before the next<br>
>release.<br>
><br>
>cheers,<br>
>--renato<br>
<br>
See another thread: there are several competing Fortran frontends based on LLVM<br>
<br>
<a href="http://lists.llvm.org/pipermail/llvm-dev/2020-January/138194.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-January/138194.html</a><br>
<br>
I hope we can wait for the community to evaluate these implementations<br>
and think how to collaborate before rushing and making one "official".<br></blockquote><div><br></div><div>I believe we're already long past this stage: </div><div>- <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html" target="_blank">[llvm-dev] RFC for f18+runtimes in LLVM</a></div><div>- <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-April/132019.html" target="_blank">[llvm-dev] [RFC] Renaming f18....</a></div><div>- <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-April/131703.html" target="_blank">[llvm-dev] f18 is accepted as part of LLVM project!</a><br></div><div><br></div><div>As far as I understand, we're now at the stage of the process where we're looking to bring the development of flang in-tree so that all parties interested in Fortran support in LLVM can collaborate. My understanding is that the f18 codebase has been accepted as the basis for starting this collaboration last April, but that does not preclude any change (including major rewrites) to happen in-tree.</div><div>After all, Chris wrote that <i><a href="https://www.aosabook.org/en/llvm.html#footnote-8">none of the subsystems in LLVM are really good until they have been rewritten at least once</a></i> ;)</div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div>