I have to be honest here… every time I’ve seen/read you say this I always wonder which metric is that one. Yet, I do go and upgrade flang, and so far it hasn’t been able to compile any of the codes I use, my own or from the Fortran community.
I fully agree with this, I’ve been extremely impressed with the pace at which Lfortran has progressed and I’m extremely eager to see it becoming a reference in the Fortran world!!
I compiled LLVM Flang recently from git, and it seems to compile all the codes I tried. It seems to be in a very good shape.
I’ll have to test the new release then once it is available through some standard channel… my limit is compiling the compiler…
@rouson has already given you his opinion, that I completely agree with, but I’ll nevertheless add my two cents here.
I have several (medium- to large-size) Fortran OO codes, that make extensive use of modern Fortran features. I could list here all of these features but this is beyond the point. What is important is that even the latest gfortran-15 version is incapable of compiling or running any of these codes correctly.
In contrast, once @certik and team got fpm to compile, it took them only two weeks or so to get the first two of my codes to compile and run correctly. At this rate, I am absolutely convinced that it will only take them a few additional weeks to be able to run also all of the other codes. The rate at which they fix bugs is literally orders of magnitude faster (think hours, instead of months or years) than the standstill that I have experienced from gfortran over the last decade.
Thus, I am absolutely convinced that LFortran will become at least as reliable on modern Fortran code as Flang already is. With the added bonus that LFortran will moreover support traits and generics in the language soon enough.
The times where Fortran development was slowly crawling are gone for good. Strangely, most of the readers on this forum do not seem to have realized this yet.
In my linux system the command man lfortran does not mention the option --no-style-suggestions.
Use lfortran --help to get a list of the supported compiler options. Here is an excerpt:
Warning Options:
--no-warnings Turn off all warnings
--no-style-suggestions Turn off style suggestions
--style-suggestions Enable style suggestions
--no-error-banner Turn off error banner
--error-format TEXT=human
Control how errors are produced (human, short)
I think we have had quite different experiences with flang bugs 
, I think I found 4 in Dec last year just by trying to get it to compile stdlib and my own little project. Having said that, the flang team seems to be very quick at fixing any issues, and it’s nice to see that there are several open source options 
@hkvzjal thanks for that feedback. Which flang versions have you tried? LLVM flang has advanced quite a lot in recent versions. It first became usable for me in version 19 with a couple of experimental flags. Starting around version 20 if I recall correctly, I no longer needed any experimental flags. It just works by default. If I had to guess and this really is just a guess, flang might be better with modern code than with legacy codes – especially if those legacy codes use non-standard compiler extensions (some of which are so common that people might not recognize them as extensions). LLVM flang 22 was just released a few weeks ago. If you try that, please post bug reports as [llvm-project GitHub issues](GitHub · Where software is built) and tag me (@rouson) in a comment on the issue if you don’t mind. I don’t do any work internal to the compiler but others with whom I work closely do. I’m curious to see the issues and will discuss them with others if I think doing so will help move things along.
flang-22 is available through homebrew at least. I was able to use it to compile stdlib 0.8.1 (without xdp or qp support), and only two of the tests fail (I will post more details in your issue about flang in the stdlib repo).
I also have to commend @certik and his team on their pace of development. The past few months I’ve been attempting to compile the old NIST Fortran Compiler Validation Suite for Fortran 77 compliance. Many issues have been PRed, and many have been fixed. Still some to go - mostly in details of formatted I/O.
There are a few F77-isms lfortran doesn’t support - which the current Standards have either deleted (E.g., H edit descriptor, ASSIGNed formats, PAUSE, etc.) or declared obsolescent (alternate RETURNs). But I’m not going to be That Guy ™ to ask for them to be supported.
@kamelstekspizza I love package managers and use Homebrew for most installations. However, I have run into two gotchas with using Homebrew to install LLVM flang. One is that the Homebrew installation of flang doesn’t include OpenMP support as far as I can tell (unless I’m missing something). The second is that flang (understandably) installs to a different path from Homebrew’s llvm package, which leads to clang not being able to find the ISO_Fortran_binding.h header file that gets built with flang. For these reasons, I typically build flang from source.
In cases it’s helpful to anyone, my script for building flang, which uses Homebrew to install prerequisites, is in the handy-dandy repository [here](handy-dandy/src/fresh-llvm-build.sh at main · rouson/handy-dandy · GitHub), but the script is better for reading than for running. I have made no attempt to get it to work on systems other than ones that I personally use regularly.