@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.
@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.
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?
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.
@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.
@patsuggested 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!
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.
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.
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.