[PROPOSAL] Rename `flang-new` to `flang`

[Meinersbur]

@clattner

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.

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.

[1] [llvm-dev] [RFC] Renaming f18....

[2] [llvm-dev] [RFC] Renaming f18....

[h-vetinari]

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.

[tschuett]

One option is to ship flang-new and flang with the next release and announce flang-new will disappear with the release after that.

[banach-space]

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!).

@Meinersbur

I don’t even know understand why the driver today is called flang-new when [2] explicitly mentioned the driver should be called flang.

That’s because there was a bash script, called flang, that would:

• call “LLVM Flang” to parse and unparse Fortran files, and then
• call 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:

• for a long while, “LLVM Flang” used to include a tool called flang.

I don’t recall that causing any friction or name clashes with other projects:

@clattner

community members seem concerned about hybrid situations where there are other compilers named flang on the system

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 flang as opposed to flang-new. Eventually, flang-new will be renamed as flang and the diagrams reflect the final design that we are still working towards.

As for CMake support,

@h-vetinari

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.

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

[greg63706]

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>.

[clattner]

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:

• There is a great concern about getting LLVM’s flang out to many people to build distribution and a user base, but also a great sense of responsibility to make sure we do so in a way that doesn’t lead with bad impressions. The sense of responsibility felt to the user community is powerful and I love it.
• LLVM’s flang is somewhat early (seems like a 0.8 level of maturity) and undergoing architectural changes, including major changes to the lowering strategies.
• it has come a long way: it now generates “error: unimplemented” errors instead of just doing the wrong thing, and the number of known miscompilations is greatly improved.
• That said, there are a large number of important code bases it cannot compile yet, including SPEC, netcdf, hdf5 and others. This doesn’t make it useless, but it isn’t as widely useful as folks want.
• No one on the call wants the existing “flang” in package managers (like homebrew, freebsd, rpm, etc) to get silently replaced with LLVM’s flang, because that will break existing users. We want increased and new distribution, but don’t want to break anyone.

After discussing a number of different aspects of the project, we came to a pretty actionable proposal that everyone agreed with:

1. We should remove the need for the -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.
2. We should update the LLVM’s public flang web site to project an image of “still being in development”, and advertise a “0.8” level of maturity. The -v flag should also advertise this - it is completely ok for flang to have its own versioning that parallels the LLVM version number.
3. We should rename the ‘flang-new’ driver to ‘flang’ in the LLVM monorepo, but only when the code matures a bit more. Please follow flang in discourse to track its status.
4. We should start our own packaging efforts (it sounds like Brad will help take the lead around this) to package LLVM’s flang compiler into an “llvm-flang” package that can live parallel to the existing PGI “flang” package. When the LLVM flang compiler matures, we can look into it subsuming the existing “flang” package completely. I don’t know what the concrete versioning will be, but there is already precedent in clang (e.g. on a mac it reports itself as Apple clang version 14.0.0 (clang-1400.0.29.202)).
5. We should look at various existing distributions of LLVM C++ compiler to make sure they don’t install the flang driver, or that they install it as “llvm-flang” until it matures. We don’t want users to accidentally be broken by a “/usr/bin/flang” overwrite just because the LLVM package is built and installed.

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

[h-vetinari]

@clattner

We should rename the ‘flang-new’ driver to ‘flang’ in the LLVM monorepo, but only when the code matures a bit more. Please follow flang in discourse to track its status.

Did you all agree on some requirements/goals that need to be satisfied, or is this a kind of “when it’s ready” criterion?

[everythingfunctional]

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.

[rengolin]

@pogo59

I suppose one of the relevant questions here is: Has the future arrived?

It’s arriving tomorrow, according to the “track my package website”.

[rengolin]

@clattner

No one on the call wants the existing “flang” in package managers (like homebrew, freebsd, rpm, etc) to get silently replaced with LLVM’s flang, because that will break existing users. We want increased and new distribution, but don’t want to break anyone.

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.

[arrowd]

Does anyone know who the existing flang users 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.

[BradSmith]

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.

[tschuett]

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.

[brooks]

Like OpenBSD we removed classic flang from the tree a while ago. At the time I didn’t think anyone was aware it was being ported forward, but at this point all our infrastructure for Fortran uses gfortran so the impact was low.

If it breaks the impasse I’d be happy with flang being installed as llvm-fortran for 17.

[klausler]

llvm-fortran would be a perfect permanent name as well.

[tschuett]

No. This was already discussed above. It must be Flang and Clang. As an intermediate step you may prefix Flang with llvm to avoid confusion with the classic flang. IMHO, llvm-flang is an improvement over flang-new.

[rengolin]

Strongly agree here. Branding is hard. Naming is hard. Managing packages is hard. Removing flang from the name throws a massive sideways wrench in all those hard problems.

Some distros use git-<package> or <package>-git to show that this is a development version of the package named <package>. It is widely accepted that git packages are the same as their non-git counterparts in functionality, only more unstable and with new features.

Naming it flang-git or git-flang would also be technically correct, since we are using git.

But in the end, anything that has flang in its name is better than any other alternative.

[everythingfunctional]

This is a thought more than a proposal, but in our conclusion above we suggested that packagers should install flang as llvm-flang (at least for now), but it’s named flang-new in the repo. Should we change the name in the repo to llvm-flang to make that clearer and give packagers one less thing to do?

Playing devils advocate a little bit, is changing the name to llvm-flang for now making it less likely that there will be strong support to change it to just flang later? Since llvm-flang doesn’t seem as much like an obviously temporary name as flang-new?

Given that we’re not renaming it to its “official” name yet, I don’t really have that strong of an opinion on what its temporary name is.

[everythingfunctional]

The patch has now landed to remove the -flang-experimental-exec flag. You can now compile with just flang-new hello.f90

[h-vetinari]

@h-vetinari

Did you all agree on some requirements/goals that need to be satisfied, or is this a kind of “when it’s ready” criterion?

@everythingfunctional

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.

Is there a way to follow the progress on the HLFIR effort, e.g. any of: a tracking issue, a milestone, a project, a status page? I checked for all 4 without success, but maybe I’ve missed something.