[llvm-dev] Flang landing in the monorepo - next Monday!
Fangrui Song via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 13 18:25:49 PST 2020
On 2020-01-13, Renato Golin via llvm-dev wrote:
>On Mon, 13 Jan 2020 at 06:50, Eric Christopher <echristo at gmail.com> wrote:
>> 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.
>
>Agreed.
>
>> 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.
>
>Before this thread, I thought the progress of F18 was much further
>than it is. My initial comments assumed it.
>
>Now, I am surprised it's not using LLVM API yet (a clear and
>consistent complaint of the previous one), as well as having its own
>driver, test infra, etc.
>
>The lack of C++ compatibility may look small now, but once we want to
>move to a newer standard, Flang will be the bottleneck. In a monorepo,
>these things are even more important.
>
>F18 was supposed to be a whole new front-end, from scratch, but it
>looks to have carried along many of the previous projects' flaws.
>
>I really wouldn't like to see the next release with such wide range of
>incompatibilities.
>
>So, +1 to both waiting the release branch as well as a concrete plan
>with a deadline to address all the critical issues before the next
>release.
>
>cheers,
>--renato
See another thread: there are several competing Fortran frontends based on LLVM
http://lists.llvm.org/pipermail/llvm-dev/2020-January/138194.html
I hope we can wait for the community to evaluate these implementations
and think how to collaborate before rushing and making one "official".
More information about the llvm-dev
mailing list