Hello Federico,
I found an issue regarding LoopControl and GCC 10 that makes use and development of the ET (nearly) impossible. I might be mistaken, but I think this deserves to be looked at ASAP, so I copy the ticket I just created (https://bitbucket.org/einsteintoolkit/tickets/issues/2404/loopcontrol-fortra...) here too.
Thank you for the report. This is indeed a serious issue that needs addressing. You say specifically LoopControl though the error seems to be generic and affect everything using CCTK_PointerTo (see https://bitbucket.org/einsteintoolkit/tickets/issues/2403), does it?
Turning on the options -fallow-argument-mismatch and -fallow-invalid-boz restores the behavior of previous versions, and silences most of the compiler complaints.
I was not even aware that "-fallow-invalid-boz" was also needed to restore previous behaviour. Thank you for pointing it out.
However the following error persists:
/.../Cactus/arrangements/Carpet/LoopControl/src/type_sizes.F90:17:33: 16 | type_sizes(1) = CCTK_PointerTo(vec(2)) - CCTK_PointerTo(vec(1)) | 2 17 | type_sizes(2) = CCTK_PointerTo(space(2)) - CCTK_PointerTo(space(1)) | 1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (TYPE(lc_space_t)/TYPE(lc_vec_t)). make[3]: *** [/home/fritz/Cactus/configs/sim/config-data/make.config.rules:412: type_sizes.F90.o] Error 1 make[2]: *** [/home/fritz/Cactus/lib/make/make.thornlib:113: make.checked] Error 2 make[1]: *** [/home/fritz/Cactus/lib/make/make.configuration:179: /.../Cactus/configs/sim/lib/libthorn_LoopControl.a] Error
This is somewhat odd since it is of exactly the type of error message that "-fallow-argument-mismatch " show suppress. May the use of TYPE() to declare the variables is the issue? I had similar argument type mismatch errors when compiling with gfortran 10, yet adding "-fallow-argument-mismatch" to my option list and compiling from scratch (best is to remove configs/sim to be very sure nothing of the old configuration information remains) let me compile. It then fails to link, yet that might be an OSX only issue and is in any case unrelated to compile time failures.
i.e., some kind of type mismatch persists in file type_sizes.F90 in LoopControl. This appears to be the case in the latest Turing release as well as in the past Proca release (LoopControl code essentially didn't change between the two). GCC versions prior to 10.1 (i.e. 9.3 and older) handle this code with no problems.
I am not sure how easy this will be the fix. The function in question, CCTK_PointerTo legitimately takes Fortran arrays of different types as arguments. In that manner it is not different from eg the MPI_Send routine in MPI which is called like so:
program test
implicit none
include 'mpif.h'
integer :: myint real :: myreal integer :: ierr
call MPI_Send(myint, 1, MPI_INTEGER, 0, 0, MPI_COMM_WORLD, ierr) call MPI_Send(myreal, 1, MPI_REAL, 0, 0, MPI_COMM_WORLD, ierr)
end program
ie has the same issue and is perfectly fine with different types due to eg the MPI_INTEGER and MPI_REAL constants telling MPI what type is being passed in.
I'm inclined to think that this is not a compiler bug, but a bug (or rather an oversight) in the ET code. The fix might be trivial but I'm not familiar enough with FORTRAN to propose one myself.
It might not be a bug, yet if it affects MPI using code in the manner above I would judge its estimated lifetime short.
Note that LoopControl is required by several key thorns (e.g. ML_BSSN, ML_CCZ4, WeylScal), and others make use of it without explicitly declaring it in their configuration.ccl (e.g. SetMask_SphericalSurface), so trying to remove LoopControl from the thornlist makes the ET almost unusable. This seems to need a hotfix.
Yes, a fix will be backported to release version. Right now I would have thought that "-fallow-argument-mismatch" would work as workaround and seem to have been successful compiling the ET (Turing) using gfortran 10 on OSX using macports.
Since this did not happen to me (and LoopControl using FORTRAN code in rare), can you maybe attach an example code to ticket https://bitbucket.org/einsteintoolkit/tickets/issues/2403, please?
This might not be a problem just yet on clusters, since they often don't offer the very latest compiler version (but this will most likely change in a few months, or maybe just weeks). On personal laptops and workstations it's a different story, many people might just get a software update from their OS vendor shipping GCC 10 and find out the ET doesn't build anymore (as it happened to me).
Yes, this definitely needs to be addressed.
Yours, Roland