Was there ever a decision or some other outcome that came of this?
I noted a couple of hlfir commits recently, and saw that there’s a new undocumented flag for using it. I presume “when the HLFIR work is landed” includes the removal of that experimental flag as well, or what’s the threshold otherwise[1]?
given that changes (=“work”) on HLFIR will presumably be continuing in perpetuity, as for any part of flang ↩︎
I haven’t been able to get hold of @clattner to hold the meeting between review managers and finish the process.
Still nothing.
Hi all,
I’m really sorry for the delay getting back to this, this happened to be an extremely busy couple months for me for other reasons. I see that this is a very pressing problem and is causing friction in the LLVM community, so I’m thrilled we’re using the decision making process. That said, in the future, I would appreciate it if we could all follow the process (specifically the "share a draft with Chris for feedback ahead of running the review): I didn’t find out about this until it was over a month in because I wasn’t following this section of the forum closely.
In any case, while I don’t think we will be able to resolve this overnight, I would like to get the review managers together for a zoom call - I’m sure all of our schedules are a mess, so a call on the weekend is probably the best. Could you each email me at “clattner” AT llvm.org with your availability for May 26/27/28?
In addition to a zoom, in order to encourage async discussion over the next week, I pulled together some notes from my reading of the proposal and the review thread. This is a quick summary intended to capture directional feelings from people and initial thoughts, I’d love to know if I got anything seriously wrong, and what people think about the comments I add.
Is “flang-new” aka “f18” is mature enough to be renamed “flang”? We have a bit of an unprecendented situation where an LLVM project is taking the name of an already established compiler. Everyone seems to want the older flang to fade away, but flang-new is not as mature and it isn’t clear when and what the criteria should be for that.
Secondary issues:
The macro issue is that this is perhaps the first time an LLVM project aims to replace an existing widely used compiler with the same name. Typically we introduce new names: clang vs gcc, pgcc vs gcc, lld vs ld/ld64, etc. This way you can have both side by side and not be confused. Mehdi points out that user’s end up with a symlink to pick an implementation, but that’s a “selecting an implementation” thing (another analog is xcode-select on macs), but each implementation still has distinct and easy to reason about identity.
Proposal is two things: one is default -flang-experimental-exec on, and other is rename flang-new to flang.
==> Are there any objections to defaulting -flang-experimental-exec on? Maybe that is a good first small step in the right direction?
Comment on motivation: Complains about status updates being “particularly well publicized, been relatively vague, etc” which seems unrelated to the name of the driver. Renaming the driver won’t cause less-vague or more publicized updates. I can see how there are barriers to adoption here though.
==> the proposal’s motivation should directly address the core issues that the proposal will address, not unrelated issues in the flang community.
It is not clear to me that renaming the command line tool will increase the size of the audience or gain more developers. The proposal should clarify this if it is a goal.
Impact on Other Projects: Agreed there is no significant impact on other LLVM projects, but community members seem concerned about hybrid situations where there are other compilers named flang on the system. It isn’t clear how the LLVM community should weight those concerns though.
==> The proposal should address this issue head on and share the advocates view of why this the right thing despite this conflict.
The proposal sort of skirts around the immaturity issues with flang-new - it has made tremendous progress but does not seem large scale production quality at the moment. What is the current state of development? Is “flang-new” development still vigorous and proceeding? Has a recent maturity cross-over point been reached which justifies the transition point? For opponents to this change, what do you think are the reasonable threshold for making a change? (this was addressed in comments on the thread).
==> The proposal should tackle these issues heads-on instead of avoiding sticky points.
I would love to see an updated draft of the proposal. I think that would help ratchet the discussion forward. This is the chance for the proponents of the proposal to directly address the opponents points, it should ideally be done so in the proposal itself.
jeffhammond: Argues we can provide a single driver named “flang” that takes a flag that picks the implementation.
==> Seems weird for LLVM project to provide an Uber-driver for other projects’ compilers. There are precedents for this (e.g. very early clang’s driver written in python did this) but that was with a new name and for other reasons. Fortran users seem to have many different compilers already and need to select them in their make files anyway.
Old web sites refer to “flang” generically, and it unclear what compiler they are referring to.
==> This seems like a potentially huge issue to me, regardless of what “flang -v” says to a user on the command line, it is important to understand what compiler some documentation online is referring to. It would be great to address this head on in the proposal.
tschuett: Flang-new web site could be improved to be more user-centric
==> I’m sure this is true, but doesn’t seem like the core issue.
sscalpone: Criteria for doing the rename is when HLFIR lands.
==> It isn’t clear to me as a non-flang person why or what user-benefit this would provide, I’d love more explanation here as I’m not familiar with flang community or technical issues. Without a better understanding, I don’t see why an internal implementation detail of the implementation would be the gate, it seems like a more objective user-centric criteria like “builds all of spec and this other codebase” would be appropriate.
mehdi_amini points out that clang was named that from the beginning despite being immature.
==> Seems not very relevant though given there were no other clang compilers to cause confusion.
tstellar observes that we decided ‘flang’ was important enough to the LLVM project to take it into the mono repo in the first place, so we should give it its name.
==> Seems like a proxy for “why does the LLVM project care about other compilers in the ecosystem”?
sscalpone points out that flang-new is not fully mature, cannot yet build SPEC 2017 and performance isn’t always there.
banach-space points out that setting criteria for rename leads to moving goalposts.
==> Maybe the criteria was never set right before?
There are some very strong statements that “flang” is the only name that can be considered. It isn’t clear at all to me that is the case. We should consider this along with the other paths forward:
==> flung, fling,flong, fnf. We could follow gnu convention and name this “lfortran”, or even go back to f18 or some wholly new name.
==> This approach has the major benefit of making it much more clear “which flang” random things on the internet are referring to, and I’m sure would define away confusion when speaking verbally and when any individual team is planning migration from one thing to another.
Clearly needs more discussion, and I would like to get people together into another medium (e.g. Zoom) to do so. There are several paths to consider:
-Chris
A project of that name exists already (and is effectively in friendly competition with flang). It’s not relevant to this thread, but since LFortran’s tagline “Modern interactive LLVM-based Fortran compiler” could be confused for flang’s mission statement as well, here’s a discussion of what the differences are.
PS. I didn’t feel I’m close enough to the development process here to comment during the RFC, but as someone involved in packaging (needing to build & distribute packages that include Fortran), I’ve long been interested in having an open-source Fortran compiler, and would vastly prefer an imperfect flang over flang-new -flang-experimental-exec. We’ll probably carry patches to achieve this within the conda-forge ecosystem in any case. This aligns with similar statements from other packagers in the previous thread.
As an update on this, one reviewer said they were unavailable this weekend, one was available this weekend and two didn’t respond. I’ll try though DM to find a time to discuss.
This would repeat a past discussion that concluded into “the goal has always been to have an upstream fortran compiler called flang” [1,2]. This is why f18 was renamed into “flang” in the first place, and I don’t even know understand why the driver today is called flang-new when [2] explicitly mentioned the driver should be called flang. If it was we wouldn’t have the discussion now.
Another point that would make renaming difficult: flang has existed (even if not fully mature) in LLVM for over 3 years now, and other projects have adapted to that. Aside from causing less-than-ideal optics about LLVM project management, changing the name would mean all projects who have started relying on flang being named flang would have to update.
For example, CMake added support for llvm-flang in 3.24, and aside from churn on CMake side, a rename would cause additional pain as then all users needs to wait for (resp. upgrade to) a new CMake version in order to be able to use a renamed flang with CMake.
One option is to ship flang-new and flang with the next release and announce flang-new will disappear with the release after that.
I agree with @Meinersbur - it does feel as if this discussion is converging towards something that was already concluded 4 years ago (thank you for sharing those links!).
That’s because there was a bash script, called flang, that would:
gfortran to compile the unparsed file.So, there was a name clash within “LLVM Flang” and we had to come up with some other, temporary name. The script was finally renamed last year: ⚙ D125832 [flang] Rename `flang` as `flang-to-external-fc`. I think that the motivation for keeping that bash script as flang is irrelevant here. What’s more important is that:
flang.I don’t recall that causing any friction or name clashes with other projects:
In general, we have already agreed that the driver will be called flang and this has been documented in various places. For example, from FlangDriver.md
NOTE: The diagrams in this document refer to
flangas opposed toflang-new. Eventually,flang-newwill be renamed asflangand the diagrams reflect the final design that we are still working towards.
As for CMake support,
it’s also has been developed with the imminent renaming in mind (from flang-new to flang)
CMakeDetermineFortranCompiler.cmake. Specifically, to save users from having to update their scripts (or CMake itself) once the renaming finally happens.
HTH,
-Andrzej
If anything rename flang-new to flang-<llvm-version> and create symlink flang to flang-17. In our downstream(local) development compiler, we used to link flang to clang-17 where we maintained the driver for the legacy pgi flang. clang, clang++ have long been links to the single binary clang-<llvm-version>. We recently changed that link to a new binary called flang-legacy in preparation for LLVM flang. This allows us to remove our local clang driver support for old flang. Our plan was to link flang or set FC to flang-new to help transition to LLVM flang.
Summary: Changing flang-new to flang-<llvm-version> and linking flang to flang-<llvm-version> is preferred. This is consistent with the links of clang and clang++ to clang-<llvm-versin>.
Hi Everyone,
We had a productive call with @rouson, @everythingfunctional, @sscalpone, @psteinfeld and myself on June 5, 2023. I took a few incomplete notes on the discussion, which was wide ranging. A few things came up:
After discussing a number of different aspects of the project, we came to a pretty actionable proposal that everyone agreed with:
-flang-experimental-exec flag. There’s no need to hide things to this level given the evolving maturity of LLVM’s flang. This will be an immediate improvement for all flang-new users.-v flag should also advertise this - it is completely ok for flang to have its own versioning that parallels the LLVM version number.Apple clang version 14.0.0 (clang-1400.0.29.202)).I want to thank the review managers for a balanced and thoughtful discussion on these topics. It is very clear that everyone involve has the success of LLVM’s flang project in mind and the friction we saw earlier was the result of different opinions on how to get the compiler out more people.
-Chris
Did you all agree on some requirements/goals that need to be satisfied, or is this a kind of “when it’s ready” criterion?
I don’t want to speak for @sscalpone , but my understanding from the discussion was “once the HLFIR refactoring is done”. I don’t have a more concrete acceptance criteria than that.
It’s arriving tomorrow, according to the “track my package website”.
Last time I looked at it was a long time ago, but my impression was that the existing flang wasn’t complete either and quite often broken. People I speak to in the HPC community still use gfortran and proprietary ones.
Does anyone know who the existing flang users are and what do they actually want? Who knows, maybe they’d be happy with the new one?
It seems the new flang will not be in production mode for quite some time yet, but as long as it’s markedly better than the previous one, it should be ok to move.
So, if there is pressure to rename to avoid confusion, then there has to be a pressure to avoid confusion to rename. It may not be priority number one to fix small compatible bugs for production code, but if it gets the rename out of the way, then working on them will be worth it.
Does anyone know who the existing
flangusers are and what do they actually want?
Speaking of FreeBSD Ports/packages: nothing uses flang to build anything. Existing llvmXY packages just include the Flang executable.
From an OpenBSD ports/packagees perspective. At one point we did have a Classic Flang port, but have not shipped anything for 3 years. There were a number of issues with Classic. Completing this is pretty important towards us eventually having a new Flang port/package and I’m keen to having something based on the new Flang.
The classic flang is shipped as proprietary flangs.
I like the proposal to ship flang-new as llvm-flang as an intermediate step.
> llvm-flang -v
Flang v17.0.0. Warning: Do not use it in production yet.