I’m trying to push to get Flang easier to try out by default, but I could use some support convincing a few people. If you want to see this happen any time soon, please leave a comment here:
Great effort, kudos.
It will be nice to read constructive and collaborative responses that get posted to your questions here.
To be brutally honest, to my non-“PC”-eye, I see a crucial vendor and its reps adopting strong elements of passive-aggressive behavior, all of the points from Mayo Clinic can be ticked as present, particularly the timing aspects and how long the effort is taking. It is a very bad look for Fortran generally as evidenced by a genuine question here that then gets flagged.
Something is seriously amiss and it is a matter of worry for Fortran.
A question for both @everythingfunctional and @FortranFan. Reading the thread linked by @everythingfunctional, I get the impression that release of a working version of Flang will be delayed until NON_STANDARD features like openMP and openACC are completed. I’m basing this on the following quote by sscalpone
The first goal is in good shape for standard Fortran features. I don’t know if
the OpenMP and OpenACC implementation have done the same. I expect
that most Fortran codes will use one or the other. It is important to
present the not-yet-implemented features in a good light.
I don’t think that the statement that using one or the other (of openMP or openACC) is true. With a working implementation of co-arrays they would be my last choice (at least on a large HPC system). Frankly, if I was running the Flang project, the following would be my approach.
-
Implement the features/capability define in the standard (and only those features (no DEC extensions) etc. Deliver a working compiler (as in generate an executable binary) in a manner (apt install, or some package manager etc) based on ONLY the standard features that users could evaluate.
-
ONLY after a standard conforming compiler has passed a sufficient number of tests do you add NON-STANDARD extensions (DEC, openMP etc)
I get the impression that the flang developers are trying for perfection and have forgotten that " perfection is the enemy of good enough"
So my question is : Is my interpretation of the priorities of the flang developers correct?
1 Like
I have thoughts, but I’m trying to be diplomatic.
To a degree yes. The priority is, and has always been, to produce a compiler that existing code bases can use with success. Specifically (at least for the DOE, who have provided a significant amount of the funding for the project), the priority is for software targeting execution on super computers. That means legacy extensions, openMP and maybe some openACC. I agree that I’d rather use the modern features of the language rather than the extensions, but that’s not where a lot of existing code is. I’ll be pushing for finishing the modern features as soon as the current priorities are reasonably well implemented.
I will say, we are pushing to make progress and priorities more visible to the general public. That’s also why I’m making the push to get the default builds to have flang be easy to use, so the more general public can provide feedback. I’m hopefully more people will try it out and let us know what they think.
1 Like
FYI, I have officially submitted this change. Crossing my fingers it can be accepted. 
3 Likes
Yep, sorry for the mistake. I’ve corrected it.
Just to be clear, I need as many potential flang users as possible to please publicly voice their support for this. Without that I’m worried the few opposing voices (most of whom are developing a competing commercial product by the way) will be able to continue to deny/delay this change. So please, if you are at all interested in how this goes, let the flang and LLVM communities know your opinion.
1 Like
Oh my!
The LLVM flang project is 100% open source. You can take it and build it. There are no restrictions beyond the Apache 2.0 license with LLVM modifications. There’s a driver. There’s a runtime library. There’s an active development community that has pushed 10 commits just today – about par for any given day.
There’s a public TODO list of what’s left to do. There’s a design review process to share what’s being implemented. Bugs are tracked in LLVM’s Github issues list. Code reviews happen in LLVM’s Phabricator. There’s LLVM’s discourse and a Slack channel. And an open phone call every week. The call info is published on a link from the llvm.org home page.
@rwmsu FWIW, NVIDIA’s contributions are 100% focused on implementing standard Fortran.
@FortranFan Thanks for the diagnosis. I’ll bring it up with Eliza 
@Steve welcome to the Fortran forum! It’s been a long time we talked. Thanks for the information. If you want to collaborate, let me know, I am always interested!
Yo! Hi @certik! LFortran is looking pretty sweet.
Have you thought about adopting the flang runtime? I think it has a pretty spiffy format parser.
1 Like
Thanks @Steve, that’s timely! We don’t have a format parser yet, I was putting the job off, but now it’s time to do it. Let me have a look.
FWIW, NVIDIA’s contributions are 100% focused on implementing standard Fortran.
On an unrelated note, I’m happy to hear about NVIDIA’s contributions. I’ve seen them post nvfortran is waiting for llvm-flang to be complete before nvfortran makes significant standard-adopting changes, but it wasn’t clear how actively they were a part of llvm-flang.
Thank you @Steve for all your efforts.
Please note if Eliza is anything like “Alexa” where I cohabitate, don’t even bother!!! - ain’t gonna listen - Alexa pays attention to and takes orders from everyone but me, especially the kids and the dog …
Hi All,
I’ve taken the next step in the contentious decision making process with this. Please take some time to go make your opinions heard in the official discussion: [PROPOSAL] Rename `flang-new` to `flang` - LLVM Project - LLVM Discussion Forums
Did, suggested Ffrend (pronounced /frend/) as the name instead!!!
Intel was wise, naming its new compiler ifx to avoid any confusion with ifort. Good marketing.
Confusion causes a loss of energy and momentum.
There was always destined to be a flang to go alongside clang. It was just a question of which codebase would get the designation. The first attempt failed, but to the developers of that codebase old habits seem to die hard, and they continue to call it flang, despite the fact it is not flang.
2 Likes
Attention @greenrongreen
The teams I work with are rather disappointed with Intel. Currently the users are all forced to use -standard-semantics -warn:all -stand with the Intel Fortran compilers of ifs and ifort.
Intel, while launching a new processor ifs - wanted it to behave quite like legacy ifort and thus not standard-semantics the default and not issue all the warnings and any remarks re: standard compliance, presumably to satisfy certain other customers.
So then, the teams I work with would have preferred if Intel had also supplied a driver off-the-shelf i.e., part of oneAPI named IFS or something along such lines conveying “Intel Fortran Standard” where “standard” implies strict conformance with ISO IEC standard for Fortran. That is, IFS by default will be the same as IFX with -standard-semantics -warn:all -stand options tacked on. Here. sorry the config file solution is unacceptable.
Anyways, hope Intel manages to retain oneAPI as “free” forever: these teams only use Intel Fortran now because there is no separate licensing requirement with $$ purchases; the minute Intel goes back to the license era with Parallel Studio, etc., these teams will further accelerate the migration away from Fortran.
There is also f18. Is it the old name of the new Flang? (I think as I remember having followed news about f18 in ~2018-2019) Or the name of a part of it, the parser? We can still see f18 on the homepage of the new Flang, also called LLVM flang, which is not the classic Flang (sorry for playing with confusion ).