Flang-new compiles MGLET

Hi everyone,

I have been following the LLVM flang project for a while. I’m a Fortran developer, working full-time on the commercial CFD-CAA (Computational Fluid Dynamics - Computational Aeroacoustics) code MGLET. This code is a typical HPC code, we crunch numbers on big, traditional clusters using Fortran and MPI.

I am now pleased to say, that as of now, flang-new is able to build MGLET and run all of our basic testcases. I cannot say exactly from which date, commit or version of LLVM this became possible, but it is for sure quite recent. All of my testcases passed yesterday with a build of llvm-project from Github’s main branch.

This is impressive of the LLVM flang community. Before flang-new, the three compilers that were known to work with MGLET was GNU gfortran, Intel ifx and NAG nagfor. Cray ftn work partially, and Nvidia nvfortran compile a binary but gives various runtime errors in every single testcase I have. The fact that flang-new runs through all testcases without a single case failing on the first attempts is very impressive. I will follow up with more and bigger testcases and performance analysis at a later time.

If any of you are interested in MGLET, the core flow solver is freely available:

This codebase contains a very basic flow solver and immersed boundary implementation. On top of this we have lots of additional code in our commercial product, but my experience has shown that once the flow solver core compiles and runs, the rest of the code will do the same.

There are still a few rough edges in flang-new, and I would use this opportunity to point out a few things that came to my mind when trying to compile and run MGLET (ordered by importance):

  1. We do not use assumed-rank arrays in MGLET at the moment, but we depend on MPI_f08. Assumed-rank arrays are required to build MPICH MPI_f08, and it would be great to see that finished such that MPICH can build without any additional “secret flags”. There is already a Github issue on this.
  2. This issue on Github related to generic interface name mangling was the only one where I had to adapt code in MGLET to workaround limitations in flang-new. It was quite annoying, as there were no clues in the error message on what name or symbol that caused problems, so I had to do some blind trial and errors based on guessing in order to rework the code.
  3. GNU gfortran provides BACKTRACE() and Intel ifx provides TRACEBACKQQ() to print a stacktrace. This is really handy when debugging problems in MGLET. Usually, I avoid using compiler extensions, but this is too useful so it’s an exception to that rule. Maybe flang-new could provide something similar?
  4. The only intrinsics missing in flang-new that we use in MGLET seems to be IEEE_GET_UNDERFLOW_MODE and IEEE_SET_UNDERFLOW_MODE. They are not at all critical to MGLET and i just disabled them with a preprocessor macro (#ifndef __flang__ around their usage).

Thanks for the great effort, everyone, flang is going to be a great compiler! If you have further questions, feel free to ask.

9 Likes

Glad to hear this.

Regarding BACKTRACE, one might be able to wrap Backtraces (The GNU C Library) using CFI and get a portable (to glibc, at least) implementation of this.

I have written an extremely basic prototype of this here: GitHub - jeffhammond/backtrace_fortran: Fortran BACKTRACE without compiler extensions.

The GNU version is formatted better and includes line numbers directly if one compiles with -g. I don’t intend to work on this further but pull requests are always appreciated.

~backtrace_fortran % ./test_gnu.x
#0  0x100aaacfb in ???
#1  0x10047be6b in bar_
	at ~/backtrace_fortran/test.F90:2
#2  0x10047be7f in foo_
	at ~/backtrace_fortran/test.F90:6
#3  0x10047be93 in MAIN__
	at ~/backtrace_fortran/test.F90:10
#4  0x10047bebb in main
	at ~/backtrace_fortran/test.F90:11
~backtrace_fortran % ./test_std.x
0x10261bd78 0   test_std.x                          0x000000010261bd78 c_backtrace + 56
0x10261bd38 1   test_std.x                          0x000000010261bd38 backtrace_ + 12
0x10261bcfc 2   test_std.x                          0x000000010261bcfc bar_ + 12
0x10261bd10 3   test_std.x                          0x000000010261bd10 foo_ + 12
0x10261bd24 4   test_std.x                          0x000000010261bd24 MAIN__ + 12
0x10261be34 5   test_std.x                          0x000000010261be34 main + 32
0x1902db154 6   dyld                                0x00000001902db154 start + 2476

@hakostra What commit were you building from main?

Commit e6cbea1 - pulled yesterday.