I think it’s flang-new. That (classic) flang you showed doesn’t seem to support F2008’s recursive derived types using allocatable components —POINTERs must be used, as mentioned by the error message.
Something similar applies to older versions of gfortran.
$ flang --version
Homebrew flang version 20.1.8
Target: arm64-apple-darwin24.6.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/flang/20.1.8/libexec
Configuration file: /opt/homebrew/Cellar/flang/20.1.8/libexec/flang.cfg
Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin24.cfg
These linked lists can be setup in several ways, but fortran allows the use of allocatable arrays and derived types, which simplifies many operations. For example, to delete the entire linked list, you just need to do
deallocate( list )
and the compiler traverses the whole list with no chance of memory leaks or dangling pointers. You can also define a pointer that traverses the list in a straightforward way. I used the move_alloc() intrinsic to add to the list, members can also be removed from the list that way. The programmer has lots of options with fortran.
Here’s my pointer based linked list implementation: flt/src/nmllog.f90 at 2a08a9061ccb337df9543228d3135d0332aaa3f8 · btrettel/flt · GitHub
As I recall, my linked list implementation was based on the linked list example in this book: Fortran 90 Programming (International Computer Science Series): Ellis, T. M. R., Philips, Ivor R., Lahey, Thomas M.: 9780201544466: Amazon.com: Books
Ron Shepard’s allocatable approach is better as it’s safer and simpler. I didn’t know about that back when I wrote my logger. I think I first learned about allocatable linked lists when reading the Intel Fortran Compiler forum in the past year or two. Another mistake I made was that I made it too complicated by having separate impure and pure loggers. Eventually, I will rewrite my logger to fix these issues.
If I remember correctly, all of the recent editions of Modern Fortran Explained have a doubly connected generic link list example.
Yes. In the latest edition it is the file oo.f90 in the zip file available, free, on the ‘codes’ button at https://global.oup.com/booksites/content/9780198876571/ . Its description is in Appendix C of the book itself.
Mike Metcalf
flang 21.1.0 has made it to Homebrew.
@msz59 sadly, the Homebrew installation of flang (1) doesn’t include OpenMP support and (2) places the ISO_Fortran_binding.h header file in a location that the Homebrew gcc can’t find. Regarding (1), even if a code doesn’t use OpenMP explicitly, the capability is still useful for several reasons, including parallel builds with fpm and automatic parallelization of do concurrent. Regarding (2), I’ve requested that the flang Homebrew formula be merged into the llvm formula but received no response.
(1) Well, it does. Still, it requires installing libomp formula and, on a Linux host only, manual adding two directories with shared libraries to LD_LIBRARY_PATH to run the executable:
PROGRAM Parallel_Hello_World
USE OMP_LIB
!$OMP PARALLEL
PRINT *, "Hello from process: ", OMP_GET_THREAD_NUM()
!$OMP END PARALLEL
END
$ export LD_LIBRARY_PATH=/home/linuxbrew/.linuxbrew/lib/:/home/linuxbrew/.linuxbrew/opt/libomp/lib:
$ flang -fopenmp -L$HOMEBREW_PREFIX/opt/libomp/lib openmp1.f90
$ ./a.out
Hello from process: 0
Hello from process: 6
Hello from process: 5
Hello from process: 3
Hello from process: 1
Hello from process: 7
Hello from process: 2
Hello from process: 4
(2) I’m not sure whether gcc, be it Homebrew or system version, should find flang-installed header files including ISO_Fortran_binding.h. They (gcc) have their own versions of that file. But indeed, clang does not find it either, without a proper -I<dir> option.
If one has M multiple fortran compilers installed, and each of them supports N multiple companion cc compilers, then one might have as many as M*N combinations of header files to keep track of.
@msz59 Re: (1), thanks for the tip! That solves the issue.
Re: (2), I just corrected my previous message. I meant to write that I have requested that the flang formula be merged into the llvm formula but have received no response. The issue I’m encountering is that clang can’t find ISO_Fortran_binding.h because the flang formula installs in a separate location from the llvm formula, which is understandable for two different formulas. To wit,
git clone git@github.com:berkeleylab/iso_fortran_binding_m.git
cd iso_fortran_binding_m
FPM_CC=clang FPM_FC=flang-new fpm test
yields
In file included from ././src/cfi_function_wrappers.c:3:
././src/cfi_function_wrappers.h:7:10: fatal error: 'ISO_Fortran_binding.h' file not found
7 | #include <ISO_Fortran_binding.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
By contrast, FPM_CC=gcc-13 FPM_FC=gfortran-13 fpm test builds without error and reports passing tests (caveat: replacing 13 with 14 or 15 fails to build for reasons that I haven’t diagnosed). I suspect the difference between LLVM and GCC is that gcc-13 and gfortran-13 are installed by one gcc@13 formula and they therefore install to a common path or at least each language front end knows where to find the other’s files.
Extra care is needed when trying to use Homebrew compilers, especially on MacOS (where HB gcc won’t find many ‘system’ headers from Apple SDK) but also on Linux hosts, where, if one sets LD_LIBRARY_PATH variable or, even worse, add HB libs directories to /etc/ld.so.conf.d/, it can easily crash system executables loading shared libraries from wrong places.