Hi everyone,
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.
GCC 10 has been released in May 2020. Due to changes in the gfortran frontend, some code in the EinsteinToolkit does not compile anymore. More precisely:
From GCC 10 release notes: Mismatches between actual and dummy argument lists in a single file are now rejected with an error. Use the new option -fallow-argument-mismatch to turn these errors into warnings; this option is implied with -std=legacy. -Wargument-mismatch has been removed.
Turning on the options -fallow-argument-mismatch and -fallow-invalid-boz restores the behavior of previous versions, and silences most of the compiler complaints. 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 ```
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'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.
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.
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).
Best regards,
Federico Guercilena