Ok, I skimmed some of the threads, but I think I need a bit more background to understand the issue here.
It sounds like there are two things named flang - an “old flang” and this patch is proposing having the LLVM Flang project take over that name - a “new flang”? Is this correct?
If so, what is the old flang, how is it distributed, and when does a user end up with both of them on the same system?
Edit: Turns out that I can use a search engine, quoting this page:
“Flang (also known as “Classic Flang”) is an out-of-tree Fortran compiler targeting LLVM. It is an open-sourced version of pgfortran, a commercial Fortran compiler from PGI/NVIDIA. It is different from the new Flang (formerly known as “F18”; see https://flang.llvm.org/), which has been part of the LLVM project since 2020, although both are developed by the same community. It is also unrelated to other projects of the same name, such as GitHub - llvm-flang/flang: Fortran Front-End and https://github.com/isanbard/flang.”
So this sounds like a discussion about how mature llvm flang is and whether it is time to switch it on by default?
At present, there is nothing in the LLVM project that can be built named flang. There used to be until relatively recently, but it was a wrapper script that has been renamed to flang-to-external-fc. It basically just used the new Fortran parser, but called a separate compiler (default being gfortran) to actually do the compilation. Also, I don’t believe that flang is built by default (i.e. you have to specify in the cmake command -DLLVM_ENABLE_PROJECTS="clang;mlir;flang;lldb"), and this doesn’t propose to change that. I just want flang to be called flang, and not require a secret flag to use.
In the linked discussion, I think the reasons to hold back are clear. Let me know if these bear repeating or need further expansion.
Everything that @everythingfunctional needs is available in llvm-project for a downstream implementation of this request. It’s not clear to me why this change needs to be made in llvm-project now.
This is exactly where the disagreement lies. I contend that it has little to with how mature llvm flang is, and I’m not proposing to “switch it on by default”. I’m proposing to remove a (partially) undocumented barrier to entry for potential new contributors (namely early adopters/testers).
While this is true, I’m clearly not the only one who’d like to do it, (i.e. this post), so why make everyone manually apply it themselves?
Because the longer we wait, the more people it will negatively impact once the change is finally made.
I’m happy to re-litigate the discussion here, but I believe most of my points have been made in the prior thread.
Sorry for not chiming in earlier - I was also traveling.
That’s not how I see it. Yes, we’ve had an extensive discussion about the maturity of LLVM Flang. However, @everythingfunctional and I argue that the name of the only existing compiler driver in LLVM Flang should be orthogonal to that. In particular:
the compiler driver in LLVM Flang should be called flang,
the maturity of LLVM Flang should be communicated through clear documentation, blog posts and community engagement rather than the driver name.
The driver in LLVM Flang can generate executables - folks have been using it build Spec 2017 and other benchamrks for quite a while now. So it definitely feels “mature enough”. Also, Clang has become an extremely successful project without needing:
clang-new -flang-experimental exec <src-file>, instead of
clang <src-file>
to generate executables. Why wouldn’t similar openness towards our users not work for LLVM Flang?
I’m happy to provide more context (I spent some “quality time” with Flang’s compiler and frontend drivers) and to review @everythingfunctional patch once there’s an agreement for the renaming.
As a status check, not all of the SPEC 2017 benchmarks are working yet – wrf and pop2 still have issues. On Spec 2006, tonto is still open. There was a concerted effort from the community to focus on issues related to SPEC 2017 to clear the path for others who are working on performance-related features, such as inlining array intrinsics.
The current status of “TO DOs” is recorded in the spreadsheet F18 "not yet implemented" - Google Sheets. My takeaway from the list is that several widely-used features of Fortran are not yet implemented. That’s why I recommended Classic Flang in the thread for users today. Classic Flang still has a robust and active development community.
From a process stand point. I don’t think this thread is meant for giving feedback on the technical issue, but it’s for selecting the review managers and giving feedback on the written pitch itself. Discussion will take place on the [Proposal] thread.
I am bit confused: is “classic Flang” this project GitHub - flang-compiler/flang: Flang is a Fortran language front-end designed for integration with LLVM. ?
Why does it impact how we decide name the flang driver during the development of the compiler in the LLVM project?
You can recommend users to use “classic flang” if they need features not supported by flang, but that shouldn’t prevent LLVM Flang from starting its live.
I can’t help feeling the criterion given by those opposed to making this change have been intentionally vague, moving goal posts, making them effectively unachievable in any predictable time frame. This is the first I’m hearing of
I wonder what will be put forth as the reason to delay next? Further, the initial criterion proposed on the first patch were themselves moving goal posts with no publicly visible status:
My proposal is:
If the compiler compiles it, it ought to run.
If the compiler can’t compile it, it ought to clearly say why.
All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature
My preference is to use the NAG test suite. It is not freely available.
For number 1, what are the chances that as more legal Fortran becomes compilable and linkable, that it necessarily executes correctly. I.e. items which are satisfied under category 2, may move to unsatisfied under category 1. As new Fortran standards are released (one is coming out this year), there will be a growing list of unsupported that aren’t satisfied under category 2. Not to mention, it’s effectively demanding there be no Internal Compiler Errors (ICE), as one can almost always come up with new ways of combining/using unsupported features that haven’t been thought of. I don’t know of any compiler that has ever even come close to having no outstanding known ICEs, let alone none period.
Why are we using these unattainable, moving goal posts to dictate the name of the flang driver?
I only bring it up because one of the reasons given in favor of the renaming (this post) was to allow a FreeBSD maintainer to build flang. My advice to the maintainer was to ship Classic Flang.
The documentation says to pick 2 to 4 people that are representative of both sides of the issue. Just looking at who was chosen for review managers in the last pitch it seems like a good start might be you and @sscalpone. If you decide to expand it to 4, it might be good to pick some people who have a little less invested in the decision who can also help to moderate the proposal discussion. I’m happy to volunteer as a review manager if you do want to make it 4.
I think it should at least not be just me and @sscalpone. We’ve already been arguing it out for weeks. That’s the whole reason I invoked this process. I was kind of hoping to get some fresh perspectives. If it just ends up being the same group of us arguing all over again, I don’t know if it will have bought us much.
If I were picking those most active in the discussion so far, I’d go with myself and @rouson on the pro side, @sscalpone and @klausler on the con side. That said, we might not be particularly good candidates for
facilitating and moderating the discussion - helping to keep the discussion on-topic and civil, without trying to overtly influence the discussion
With that in mind, I think we need some more neutral parties. @tstellar , if your willing to serve as a review and have a possible 2nd in mind, I think that would be better.
Can we bring the level of heat down, please? Not everyone who disagrees is arguing in bad faith or moving the goal posts. HLFIR was mentioned in the previous thread almost a month ago.
I apologise. I must have missed something or misinterpreted something. I am passionate about open source software, that it should in fact be open and accessible, and that it should be developed in as open and accessible a way as is feasible. Unfortunately those passions can sometimes get the better of us and lead to mistakes. My bad.
I do think this underscores my point,
as it does not seem so far that we have been able to achieve the
part. So I would again ask for some volunteers to please help us move this forward.
Ditto. After extensive discussions in the thread that prompted this thread, this is my first time I’m hearing that the landing of this September 2022 RFC is a suggested criterion for doing something that has been requested since May 2022. I’m speechless.
Based on the feedback I’ve gotten, it doesn’t seem there’s much concern about the vocal parties serving as review managers. @rouson and I are willing to serve as the review managers for the “Pro” side of the discussion. @sscalpone and @klausler , would you two be willing to serve as the review managers for the “Against” side? If so, please let me know if my first draft of the proposal (the first post on this thread) is acceptable or if you think it needs changes. I’d like to get the next step done later this week.
A review manager checks the proposal into a directory (llvm/llvm-www/proposals) so it is version controlled.
Thanks @everythingfunctional . I’ll volunteer to join you as the review manager and propose inviting @psteinfeld , a Flang frequent contributor and reviewer.