The Flang doc has a Rosetta Stone for C programmers:
https://flang.llvm.org/docs/FortranForCProgrammers.html
The blog looks very much AI-generated. Judging by the page counter they’ve published O(1000) articles since January 2025.
Thanks @ivanpribec for your vigilance… I have removed the link. 
1 Like
Look at how HPCInfo/buildscripts/llvm-git.sh at master · jeffhammond/HPCInfo · GitHub uses LLVM_PARALLEL_LINK_JOBS and LLVM_PARALLEL_COMPILE_JOBS to throttle build parallelism, which is the primary cause of LLVM builds making machines go AWOL due to a DDOS on the virtual memory system. I implemented those features when I was building LLVM on a Raspberry Pi 4, which had just enough memory to link one binary at a time. Prior to using those options, it would go unresponsive, overheat, and die.
5 Likes
Nice blog post! I wonder if that means nvfortran will finally change soon, as on the NVIDIA forums they claimed they’ve been waiting for flang to implement enough to use. I need coarrays+CUDA asap!!!
I think they’ve changed already since they define compiler macros like here: NVIDIA HPC Compilers Reference Guide — NVIDIA HPC Compilers Reference Guide 25.7 documentation
1 Like
IMPLICIT NONE (type, external) still does not work with 25.7 - so I guess it’s still the legacy frontend.
1 Like
It may be to interface with CUDA C clang rather than Flang. Either way, modern Fortran features are not yet available.
Now that flang 21.1 is available in Homebrew, I am doing some simple tests. I got a strange behavior with the “bggest” integers, of kind=16. The following code:
program flang_test
integer(kind=16) :: i=2_16, j=5_16
print *, i**j
end program flang_test
gives an error msg:
$ flang fl_test.f90
error: loc("/home/msz/Devel/fl_test.f90":4:12): not yet implemented: no math runtime available for 'INTEGER(KIND=16) ** INTEGER(KIND=16)'
It took me quite a while to notice that despite the error the executable gets actually built and seems to work fine:
$ ./a.out
32
Weird 
BTW, for those using linuxbrew (Homebrew for Linux) version: flang comes with shared runtime library only (-static-libflangrt option does not work) and it does not embed the library’s path into the executables (as gfortran or gcc do). So to run them, one has to add $HOMEBREW_PREFIX/lib (typically /home/linuxbrew/.linuxbrew/lib) to $LD_LIBRARY_PATH
The code is showing i**j which should print 32, not 10. Typo or is code actually producing 10?
Surely 32. Edited to fix. ‘10’ was the output from i*j 
Multiplying does not produce any warnings/errros at compile time
program flang_test
integer(kind=16) :: i=2_16, j=127_16
print *, huge(i**j)
print *, kind(i**j),kind(i)
print *, (i**j)-1
end program flang_test
perhaps the statement is true and operations might be performed with a different kind? The last print is “iffy” but what does flang produce when values outside of the range of default integers are used?
170141183460469231731687303715884105727
16 16
-1
It is really “not supported”:
program flang_test
integer(kind=16) :: i=2_16, j=127_16
print *, huge(i**j)
print *, kind(i**j),kind(i)
do j=1_16, 127_16
print *, j, i**j
end do
end program flang_test
170141183460469231731687303715884105727
16 16
1 2
2 4
3 8
4 16
5 32
6 64
7 -128
8 0
9 0
[... all zeros ...]
127 0
I was aware of support for 64-bit integers but this is asking for 128-bit integers. “16” is not a meaningfully portable KIND number. IFX rejects KIND=16 for INTEGER outright. LLVM-FLANG issues an error message but produces an executable with broken arithmetic for KIND=16, RANGE(X)=38. The same KIND=16, RANGE(X)=38 integer flavour in GFORTRAN seems to get the arithmetic right.
Multiplication works fine. Is it possible to overload an intrinsic operator for an intrinsic type?
program flang_test
integer(kind=16) :: i=2_16, j=127_16, res=1_16
print *, huge(i**j)
print *, kind(i**j),kind(i)
do j=1_16, 127_16
res = res*2_16
print *, j, res
end do
end program flang_test
170141183460469231731687303715884105727
16 16
1 2
2 4
3 8
4 16
5 32
6 64
7 128
8 256
9 512
10 1024
[...]
124 21267647932558653966460912964485513216
125 42535295865117307932921825928971026432
126 85070591730234615865843651857942052864
127 -170141183460469231731687303715884105728
There are several libraries/modules available that support arbitrary precision that would be portable to compilers not supporting 128-bit integers as a bonus if you need to work with integers this large. The partial implementation flang is providing might have some uses, allowing for checking for overflow of 64-bit integers and increased ranges when using factorization and factorials and such but I was expecting it to still work with values in the range of the fully implemented kinds at least. The behavior you show where values using more than one byte is disturbing. I believe you cannot overload a defined intrinsic operation but you could define named operations and do something like “i.pow.j” or create functions like “pow(i,j)” but I doubt that is what is desired. I think that flang warning should be a fatal error.
Yes, these kinds of posted codes should be using parameters for the kinds, not hardwired literal constants. The iso_fortran_env intrinsic module provides those constants.
program kinds
use, intrinsic :: iso_fortran_env
write(*,*) 'real_kinds =', real_kinds(:)
write(*,*) 'real constants=', real16, bfloat16, real32, real64, real128
write(*,*) 'integer_kinds=', integer_kinds(:)
write(*,*) 'int constants=', int8, int16, int32, int64, int128
end program kinds
$ flang kinds.f90 && a.out
real_kinds = 2 3 4 8
real constants= 2 3 4 8 -1
integer_kinds= 1 2 4 8 16
int constants= 1 2 4 8 16
Note that both 16-bit floating point formats are supported, but real128 is not supported. Also, int128 does have a positive value, even if the current support is lacking.
I am a recent user of flang, so I am just now learning about how to use the compiler. The above is from the Homebrew version of flang. Apparently, if you build from source, you can enable real128 support.
The cmake line you need is
-DFLANG_RUNTIME_F128_MATH_LIB=libquadmath \
1 Like
I guess the question is why isn’t this enabled by default. Is this just the LLVM flang’s developers way of forcing people to build the compiler themselves from scratch. Also, why should users have to depend on things like Homebrew, conda etc. just to install a working binary version. Just do what Nvidia and AMD do. A tar or zip file with an install script. I presume something like this exists but the LLVM flang folks do a bad job of advertising it if it does.