<html>#2404: LoopControl FORTRAN code doesn't compile under GCC 10
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td></td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>blocker</td></tr>
<tr><td style='text-align:right'>Component:</td><td>EinsteinToolkit thorn</td></tr>
</table>
<p>GCC 10 has been released in May 2020. Due to changes in the gfortran frontend, some code in EinsteinToolkit does not compile anymore. More precisely:</p>
<p>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.</p>
<p>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:</p>
<div class="codehilite"><pre><span></span>/.../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
</pre></div>
<p>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. GCC versions prior to 10.1 (i.e. 9.3 and older) handle this code with no problems.</p>
<p>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.</p>
<p>Note that LoopControl is required by several key thorns (e.g. ML_BSSN, ML_CCZ4, WeylScal), and others make use of it without ex
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2404/loopcontrol-fortran-code-doesnt-compile'>https://bitbucket.org/einsteintoolkit/tickets/issues/2404/loopcontrol-fortran-code-doesnt-compile</a></p>
</html>