[Users] LoopControl FORTRAN code doesn't compile under GCC 10

[Federico Maria Guercilena]

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-fortran-code-doesnt-compile) 
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

-- 
Dr. Federico Maria Guercilena

Technische Universität Darmstadt

Institut für Kernphysik
Theoriezentrum
S2|11
Schlossgartenstraße 12
64289 Darmstadt
Room 302

+49 6151 16 21562

fguercilena at theorie.ikp.physik.tu-darmstadt.de