Building fortran tests with gfortran version >= 10 is broken

[markcmiller86]

Discussed in https://github.com/LLNL/Silo/discussions/324

^{Originally posted by **pkestene** May 25, 2023} Currently, I noticed that the fortran tests do not compile when fortran compiler is gnu with version >= 10, mostly because of mismatch arguments (this was just a warning with older version of gfortran, but are now considered as genuire errors by default in gfortran >= 10): ```shell /home/pkestene/install/Visu/silo/git/Silo/tests/matf77.f:250:43: 244 | . meshnms, lmeshnms, meshtypes, | 2 ...... 250 | . meshnms, lmeshnms, DB_F77NULL, | 1 Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar) make[2]: *** [tests/CMakeFiles/matf77.dir/build.make:75: tests/CMakeFiles/matf77.dir/matf77.f.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:2115: tests/CMakeFiles/matf77.dir/all] Error 2 make: *** [Makefile:136: all] Error 2 ``` This can be fixed in cmake, e.g. by modifiying tests/CMakeLists.txt, like this: if cmake detects we are using gfortran >= 10, we add a flag to allow argument mismatch. ```cmake if(SILO_ENABLE_FORTRAN AND CMAKE_Fortran_COMPILER) foreach(f arrayf77 csgmesh curvef77 matf77 pointf77 qmeshmat2df77 quadf77 testallf77 ucdf77) silo_add_test(NAME ${f} SRC ${f}.f) if(CMAKE_Fortran_COMPILER_ID MATCHES "GNU") if (CMAKE_Fortran_COMPILER_VERSION VERSION_GREATER_EQUAL 10) target_compile_options(${f} PRIVATE "$<$:-fallow-argument-mismatch>" ) endif() endif() endforeach() silo_add_test(NAME arrayf90 SRC arrayf90.f90) endif() ```

[markcmiller86]

Ok, so, it turns out the Silo Fortran interface does permit the interface to be called either with valid arrays for some data members or with DB_F77NULL in place of those arrays. So, a mixing of types used in calls from a calling program is certainly possible and ok (I was about to say possible and valid but I worry valid may be too strong a word given the age of Silo and the lack of consideration of modern fortranisms in the design of its fortran interface).

But, it would now appear using fallow-argument-mismatch may be the only means of truly dealing with this issue for for silo's test suite and any callers of Silo that might be using these calls two different ways. That said, I would not expect this mixing of usages to be very common at all. One is using explicit lists of names and the other is using the more efficient and scalable nameschemes. It doesn't make much sense for a single fortran compilation module to use both with the exception of a lazy code developer just implementing tests for a variety of ways of calling the interface :wink:. So, another way of dealing with this is to put the tests for namescheme oriented calls in a separate test.

[markcmiller86]

Resolved in #346 and #347