Building fortran tests with gfortran version >= 10 is broken #324
-
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): /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. 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
"$<$<COMPILE_LANGUAGE:Fortran>:-fallow-argument-mismatch>"
)
endif()
endif()
endforeach()
silo_add_test(NAME arrayf90 SRC arrayf90.f90)
endif() |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Good to know about the fortran compiler flags to control this. However, I do think the right answer is to correct the calls (if that is possible). I think the second of the the two cases identified here is just using the interface incorrectly and we got away with it before. I can be easily corrected. I'll need to audit the rest of the cases to resolve entirely. |
Beta Was this translation helpful? Give feedback.
Good to know about the fortran compiler flags to control this.
However, I do think the right answer is to correct the calls (if that is possible). I think the second of the the two cases identified here is just using the interface incorrectly and we got away with it before. I can be easily corrected.
I'll need to audit the rest of the cases to resolve entirely.