Compile Error with Intel PSXE 2020 Update 0

[stefan-maxar]

Hello! I was hoping to get some guidance on a new compiler error we came across after updating to the latest version of Parallel Studio XE (2020 update 0). Our application has compiled fine using Parallel Studio XE 2019 releases (updates 0 - 5), so the following has popped up with the latest release - no code modifications have been made to our application. Not sure if this is better placed in the MPI-related forum or here, so apologies if this is in the wrong place! The compile command and related error:

mpiifort -Duse_libMPI -Duse_netCDF -DSPMD -DUSE_LOG_DIAG_FIELD_INFO -Duse_LARGEFILE -DGFSL64 -DGFS_PHYS -DMOIST_CAPPA -DUSE_COND -DNEW_TAUCTMAX -DINTERNAL_FILE_NML  -DOVERLOAD_R4 -DOVERLOAD_R8  -fpp -Wp,-w -I/usr/local/netcdf-4.6.2/include -I/usr/local/netcdf-4.6.2/include -fno-alias -auto -safe-cray-ptr -ftz -assume byterecl -nowarn -sox -align array64byte -fimf-use-svml -i4 -real-size 32 -xSKYLAKE-AVX512 -qno-opt-dynamic-align -O2 -debug minimal -fp-model source -qoverride-limits -qopt-prefetch=3 -qopenmp -Ifms -Igfsphysics -Iipd -Icpl -Iio -Iatmos_cubed_sphere   -I/usr/local/esmf_7_1_0r/include -I/usr/local/esmf_7_1_0r/mod/modO/Linux.intel.64.intelmpi.default -c atmos_model.F90

atmos_model.F90(254): error #8178: The procedure pointer and the procedure target must have matching arguments.
      Func0d => radiation_step1
------^
atmos_model.F90(274): error #8178: The procedure pointer and the procedure target must have matching arguments.
      Func0d => physics_step1
------^
atmos_model.F90(294): error #8178: The procedure pointer and the procedure target must have matching arguments.
      Func0d => physics_step2
------^
compilation aborted for atmos_model.F90 (code 1)

Upon googling, it seemed as this was possibly an issue previously (see: https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/600062)? Attaching the source from which the error was created (atmos_model.F90). As this Fortran is apart of a very large and complex code base, I'll try my best to provide more details as needed but can't promise I know all the answers!

- Stefan

[Steve_Lionel]

We would need to see the source that declares procedure radiation_step1, physics_step1 and physics_step2. The compiler believes that the interfaces for these procedures don't match the (abstract?) interface IPD_func0d_proc (we need to see the source of that too)

[stefan-maxar]

Thanks the help! I've done some searching and came across the declarations for each of the requested. "IPD_typedefs.F90" contains the abstract interface subroutine "IPD_func0d_proc", while the radiation_step1, physics_step1, and physics_step2 are defined in "GFS_abstraction_layer.F90". The "IPD_driver.F90" is relevant for driving the calls of all of the above. Attaching all that source to this post.

I'm still digging on my end to see what else might be amiss that wasn't caught in Intel PSXE 2019 update 5.

- Stefan

[Steve_Lionel]

I need to see the source of module GFS_driver as this defines the routine for which radiation_driver is a rename.

[stefan-maxar]

Attaching the GFS_driver as well as the drivers for physics and radiation too. Thanks again!

[Steve_Lionel · Accepted solution]

Ok!  See the following comment (and code) in GFS_radiation_driver.f90?

! DH* gfortran correctly throws an error if the intent() declarations
! for arguments differ between the actual routine (here) and the dummy
! interface routine (IPD_func0d_proc in IPD_typedefs.F90):
!
! Error: Interface mismatch in procedure pointer assignment at (1): INTENT mismatch in argument 'control'
!
! Since IPD_func0d_proc declares all arguments as intent(inout), we
! need to do the same here - however, this way we are loosing the
! valuable information on the actual intent to this routine. *DH
#ifdef __GFORTRAN__
      type(GFS_control_type),         intent(inout) :: Model
      type(GFS_statein_type),         intent(inout) :: Statein
      type(GFS_stateout_type),        intent(inout) :: Stateout
      type(GFS_sfcprop_type),         intent(inout) :: Sfcprop
      type(GFS_coupling_type),        intent(inout) :: Coupling
      type(GFS_grid_type),            intent(inout) :: Grid
      type(GFS_tbd_type),             intent(inout) :: Tbd
      type(GFS_cldprop_type),         intent(inout) :: Cldprop
      type(GFS_radtend_type),         intent(inout) :: Radtend
      type(GFS_diag_type),            intent(inout) :: Diag
#else
      type(GFS_control_type),         intent(in)    :: Model
      type(GFS_statein_type),         intent(in)    :: Statein
      type(GFS_stateout_type),        intent(inout) :: Stateout
      type(GFS_sfcprop_type),         intent(in)    :: Sfcprop
      type(GFS_coupling_type),        intent(inout) :: Coupling
      type(GFS_grid_type),            intent(in)    :: Grid
      type(GFS_tbd_type),             intent(in)    :: Tbd
      type(GFS_cldprop_type),         intent(in)    :: Cldprop
      type(GFS_radtend_type),         intent(inout) :: Radtend
      type(GFS_diag_type),            intent(inout) :: Diag
#endif

Big news - it's not just gfortran that correctly diagnoses a mismatch in intent, Intel Fortran does too! I haven't looked but I would bet that the other routines have the same problem.

The best solution is to not lie about the interface to the procedures. If a single abstract interface is being used for multiple routines with different actual interfaces, that's not a good design. 

[stefan-maxar]

Ah yes, I see it! Thanks! I'll look into what I can do to alleviate the issue. Thanks again!

[stefan-maxar]

That did it - I modified the source to assign intent(inout) to those where they weren't in source code blocks (basically removing the if block and making all variables intent(inout) - compiles fine now. I will need to look into this more, but at least those modifications get passed the initial errors. Thanks!

[Steve_Lionel]

By the way, I have for many years encouraged the ifort team to issue more informative messages, like the one gfortran gives. I won some, lost others. This is a case where it would be very helpful to give specifics as to what was wrong.

[JohnNichols]

Saxum volutum non obducitur musco

springs to mind in relation to moving teams of people.