You can download flang packages for the current rc:
It is unlikely that 16 ships with flang instead of flang-new. It is up to you which name flang will have in 17.
As the FreeBSD port maintainer for LLVM I’m giving serious consideration to applying ⚙ D143592 [flang][driver] Rename `flang-new -flang-experimental-exec` to `flang` to our release. The other realistic option is to disable flang in the default config which means no packages.
3 Likes
@rouson: My goal was to try and find a simple way to reach the community so there is a quick way to understand what is happening and where things stand in terms of a release candidate. Nothing less, nothing more. I’m hesitant to take on anything more complex until we can find a simple way to communicate these aspects so we can come to agreement on what the feature set for the first RC will be and do the work to bring it to reality.
1 Like
Classic Flang might be a better choice for distribution until LLVM flang is further along.
1 Like
@sscalpone Classic Flang has been completely useless across every project on which I’ve worked over the past ~5 years and that’s a long list of projects, some open-source and some not. The stagnation of Classic Flang is understandable because presumably it will be displaced by LLVM Flang eventually. Presenting a stagnant compiler that doesn’t support large parts of Fortran 2008 and 2018 to the community is not a good look for Fortran – particularly when there are already four compilers that are either 2018 compliant or or at least support the most significant and widely used parts of 2018. What would be the point of building interest in LLVM Flang by presenting the predecessor that led to a complete rewrite?
@pat the goal of the automations that I described are to save time. Teams I’ve led have used the described approach across several projects for years and I don’t recall a single team member suggesting that these tools were costing time. But the openness of the described approach is equally important. One of the main points of having GitHub issues is to foster discussion – preferably open discussion when the project is an open-source project. A lack of openness about the process is one cause of the impressions expressed in the Discourse thread that I cited earlier. A spreadsheet or checklist doesn’t open the dialogue and lacks a lot of functionality that would make life simpler.
@clementval thanks for the link. That project board is a great start. A board with the level of detail that is currently in spreadsheets would be really helpful – partly because it makes it more likely that users who visit more than once will see change over time. Also, if the cards listed on that project are converted to issues, then the issue comment threads can capture dialogue, including comments from potential users or potential contributors.
Stagnant aside, LLVM Flang doesn’t support large parts of Fortran 2008 and 2018 yet.
Classic Flang may not meet the needs of @rouson, however, it has a healthy development community, several commercial instantiations, and is available for FreeBSD.
1 Like
How is this not deliberately misleading your future users? People will start using flang (as far as they know), and then when behavior drastically changes be completely confused. This is (IMO) the worst of both worlds. You’ll start getting bug reports and feature requests based on experiences with the thing you’re not actually working on. If the main argument against this renaming is not to inundate the developers with superfluous feedback, why on earth would you make this suggestion, which practically guarantees it?
1 Like
I don’t think it’s misleading at all! I expect the transition from Classic Flang to LLVM Flang to be a fairly transparent and pleasant experience.
Classic Flang has been out there for a while. Both communities have thus far been very adept at redirecting users to the proper channels.
It’s really up to FreeBSD, not me, what they choose to do.
We should listen to and support our community members who provide and maintain binary packages for LLVM Flang - ultimately they make sure that LLVM Flang reaches end users, which is vital for the success of the project. We should really avoid them having to maintain any downstream patches:
Also, can we please avoid including Classic Flang in this discussion? That’s a completely separate project.
This thread is an opportunity for the LLVM Flang community to make the life of binary package managers (and many other people) easier.
1 Like
My recommendation is to reopen this discussion after [RFC] Add higher level operations in FIR lands.
I would just like to make note, that the above comment on this thread came after my comment
on the other thread.
@everythingfunctional I moved my comment over here to continue the conversation because @tstellar suggested it was off topic in the [pitch] discussion.
The goal posts aren’t moving, but as you point out, the testing status is not publicly visible if we use the NAG suite as the measure.
@pat suggested a few open test suites and asked for suggestions.
The gfortran suite may be a good choice if you’d like to try it & report back.
Happily, the ball is still moving! There have been 31 commits to the llvm-project/flang tree this week!
But just the part I quoted as being new. None of your other points, or even a back were warrented. 
How is introducing new milestones prior to consideration not moving the goal posts?
My understanding is that disentangling that test suite from gfortran specifics is non-trivial, but I’m happy to start looking into it if it helps.
Progress is always great news. Happy to hear it.
1 Like
A bit hesitant to chime in here given I don’t work on flang, but oh well…
The current state of LLVM flang - which I think is also called F18? - is really hard to figure out from the outside. I’ve been asked about this a couple times recently by users, and my honest answer has been that I just don’t know how mature it is. There’s been some great information in this thread, but summaries should really move into the documentation. From the sound of it, flang may not be quite ready for prime time, but what it does support and what reasonable user expectations should be at the current time really should be documented.
As for the naming point, it makes absolutely no sense to me to have a flang sub-project of LLVM whose binary is not named flang. Skimming (only!) the discussion above, it really seems like the discussion is commingling issues of naming with release management, documentation, and support. I’m very solidly in the “just call it flang” camp, and think this would be actively less confusing for users.
10 Likes
I am also asked about LLVM Flang (old name as F18) by some users in China. A lot of users are interested in LLVM Flang, but it’s not easy for beginners to get involved in although @kiranchandramohan gives some tutorials of the status of LLVM Flang. Maybe setting an office hour could help. Getting Involved — LLVM 17.0.0git documentation
@sscalpone Do you mind if others instead of CODE_OWNER of LLVM Flang set the office hour to help users know more about LLVM Flang and direct them to use and contribute to LLVM Flang？Or you can set the office hour.
1 Like
Thanks @sscalpone. We are discussing the funding we can invest on LLVM Flang this year. Will let you know if I can take up this work at the end of this month.
4 Likes
I have now taken the next step in the process. Further discussion should happen here: [PROPOSAL] Rename flang-new to flang