Why is there an error with gfortran but ifort and pgf90 do not?

Question

I'm trying to install a package called ESL-bundle. One of its modules (called futile) went wrong when I tried to change the compiler.

my operation:

git clone https://gitlab.com/ElectronicStructureLibrary/esl-bundle/-/tree/master
mkdir install && cd install
#export FC=<path of gfortran> # using pgf90 by default
../esl-bundle/install-bundle --conditions +yaml futile | tee ./install-1.log

I can use pgf90 and ifort to compile it, but gfortran gives the error:

esl-bundle/checkouts/futile-1.8/dicts/f_precisions.f90:95:29:

   95 |       k=int(f_loc(a(2))-f_loc(a(1)))
      |                             1
Error: Type mismatch in argument ‘routine’ at (1); passed REAL(4) to UNKNOWN

There are some functions calculating the size of some types:

    function sizeof_r(av) result(k)
      !function documented here
      implicit none
      real(f_simple), intent(in) :: av
      real(f_simple), dimension(2) :: a
      integer :: k
      a(1)=av
         k = int(f_loc(a(2)) - f_loc(a(1)))
    end function sizeof_r

The definition of f_loc():

!> Function which identifies the address of the scalar object
!! associated to a unknown quantity
function f_loc(routine)
  use f_precisions, only: f_address
  implicit none
  external :: routine       !< Object
  integer(f_address) :: f_loc  !< Address of the object routine

  call getlongaddress(routine,f_loc)

end function f_loc

It seems that 'routine' don't have a type which causes problems.

So why pgf90 and ifort could handle this but gfortran couldn't? Can I fix it with some compiler flags?

I want to compile it with gfortran, since my program is mainly based on it.

Update: This bundle is quite old and widely used in many scientific software, so I don't want to debug or rewrite any part of it (though it seems ridiculous in today's views).

Answer 1

Finally I use the flag -fallow-argumnet-mismatch to avoid this error. And I find this flag used in its mpi version (using mpiifort and mpicc). So I guess it's a common operation in this program.

I believe there are better ways to calculate the size of types, but considering the programmers' actual job (99% scientists) and the times they wrote this program, I think there's no need to care about its internal implementation.