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

[Roland Haas]

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

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20200603/d06b30f5/attachment.bin