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 when Fortran development was slowly crawling along 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.
Be careful not to use “Classic Flang”, i.e. the old compiler that originated from PGI’s pgfortran, which as far as I know still serves as the basis for Nvidia’s commercial Fortran compiler.
The Flang that was referred to in this thread is the new Fortran compiler front-end of the LLVM project. If you are on a Debian or Ubuntu based Linux distro then you can obtain precompiled flang (and llvm) binaries directly from LLVM’s website, i.e. you don’t need to build all of this from source.
Sorry, I am not asking flang. I am talking lFortran.
Unfortunately, the last time I tried to install these binaries, flang wouldn’t work. It couldn’t find some system file ( a particular version of libc if I remember - probably a PATH problem). Note that some versions of LLVM and lFortran (albeit a couple or three versions old) are available directly from the Debian/Ubuntu repositories. Just have to do an apt-install. And if you don’t mind using the Conda environments (unfortunately I do), you can install using Conda.
I am using termux on an Android phone. It has a working lFortran, but not gfortran. I’d love to see gfortran also working on it.
I am always amazed at how many people demand that things like DEC extensions continue to be supported. My personal opinion is that the path to long term maintainability in Fortran codes is to program to the Standard and only the Standard.
We’ll support it eventually. But after we compile modern codes and get good performance.
For production codes that you want to write once and work forever, you want to use about 30 years old technology, so for C use C89, and for Fortran use F90. That will work really well both today and in the future with lots of compilers. You can also use some newer features here and there, with care.
At the same time we also want to be able to do newer features, including those not in the standard yet, so as a compiler and community we have to go beyond the standard. And yes, I agree that even with the best features and the best compilers, it might not be as reliable as F90 for some use cases, but still worth doing.
Great. Here is my test code for f23. My aim is to use this switch to compile nastran which gFortran can do.
There is no iargc().
_argc comes up in the suggestion message, but no _argc() either. Anyway command_argument_count() works. I think it is a new one. I am happy to use it.
Does f23 mean Fortran II & III?
!dmain.f90
integer a,b,c
a=1
b=2
call D_Add(a,b,c)
print *,'c =',c
call D_Enddo()
call D_LessEqual()
call D_DoubleC()
call D_ArgCount()
!call D_argc()
!call D_Iargc()
end
subroutine D_Add(a,b,c)
integer,intent(in) :: a,b
integer,intent(out) :: c
c=a+b
end subroutine D_Add
!dsub.f90
subroutine D_Enddo()
integer i
do i=1,2
print *,'enddo'
enddo
do i=1,2
print *,'end do'
end do
end subroutine D_Enddo
subroutine D_LessEqual()
integer i
i=-1
if (i.le.0) then
print *,'LessEqual'
endif
end subroutine D_LessEqual
subroutine D_DoubleC()
integer :: i=1
print *,'DoubleC'
end subroutine D_DoubleC
subroutine D_ArgCount()
! Get command line arguments
integer num_args
character(len=120) :: inp_file
num_args = command_argument_count()
write(*,*) 'num_args =',num_args
if (num_args == 1) then
call get_command_argument(1, inp_file)
print *,trim(inp_file)
end if
end subroutine D_ArgCount
!subroutine D_argc()
! if (_argc()==0) write(*,*) '_argc=0'
! end subroutine D_argc
!subroutine D_Iargc()
!if (iargc()==0) write(*,*) 'Iargc=0'
!end subroutine D_Iargc
dsub.f90 (1.2 KB)
dmain.f90 (178 Bytes)
I am guessing there will be some bugs, I think NASTRAN is a large code and has lots of F77 in it, and we support most of it, but there are some corner cases that we don’t yet. If you find them, please report them.
Does f23 mean Fortran II & III?
It means what the Fortran 2023 Standard specifies, which is for the most part backwards compatible with F66, but my understanding is that going further to Fortran IV and II, there were lots of vendor extensions and not standardized, so it’s not fully backwards compatible.
fpm actually exercises fairly nontrivial parts of the language in a few places, i.e. in the JSON/TOML serialization infrastructure and in the features/profiles implementation, where we rely on some fairly heavy OO patterns, inheritance, recursive classes, etc.. Overall, compiler support there has been encouraging, with no major show stoppers.
Once LFortran is mature enough for it (reaches beta?), adding fpm to the supported-compiler CI would definitely be a very nice milestone.
