Compiler generated interfaces stripping attributes

[jimdempseyatthecove]

Windows IVF 15.0 update 4

In Debug build (with /warn:interfaces) I get:

error #7062: The characteristics of dummy argument 2 of the associated actual procedure differ from the characteristics of dummy argument 2 of the dummy procedure.
 

The subroutine is declared as:

SUBROUTINE intdeo2_rect(crames,f, a, omega, aw, i, ERR,i_point,sit,ans)
USE dyn_array_crames

IMPLICIT NONE

type(CRAMES_t)                            :: crames
! jd: Add EXTERNAL attribute, then add the interface
! REAL(i8), INTENT(IN)                      :: f
interface
    REAL(i8) FUNCTION  f(crames,xsi,sit,ans)
        USE dyn_array_crames
        USE ieee_arithmetic, ONLY: IEEE_IS_NORMAL
        IMPLICIT NONE
        type(CRAMES_t)                         :: crames
        REAL(i8), INTENT(IN)                   :: xsi,sit
        REAL(i8), INTENT(OUT)                  :: ans(9)
    end function f
end interface

REAL(i8), INTENT(IN)                      :: a
REAL(i8), INTENT(IN)                      :: omega
REAL(i8), INTENT(IN)                      :: aw(0 : crames%lenaw1-1)
REAL(i8), INTENT(OUT)                     :: i
REAL(i8), INTENT(OUT)                     :: ERR
INTEGER, INTENT (IN)                      :: i_point
REAL(i8), INTENT(IN)                      :: sit
REAL(i8), INTENT(OUT)                      :: ans(i_point)

Note the INTENT on the interface to the function argument f

In the auto-generated module I get:

       MODULE INTDEO2_RECT__genmod
          INTERFACE 
            SUBROUTINE INTDEO2_RECT(CRAMES,F,A,OMEGA,AW,I,ERR,I_POINT,  &
     &SIT,ANS)
              USE DYN_ARRAY_CRAMES
              INTEGER(KIND=4), INTENT(IN) :: I_POINT
              TYPE (CRAMES_T) :: CRAMES
              INTERFACE 
                FUNCTION F(CRAMES,ARG1,ARG2,ARG3)
                  USE DYN_ARRAY_CRAMES
                  TYPE (CRAMES_T) :: CRAMES
                  REAL(KIND=8) :: ARG1
                  REAL(KIND=8) :: ARG2
                  REAL(KIND=8) :: ARG3(*)
                  REAL(KIND=8) :: F
                END FUNCTION F
              END INTERFACE 
              REAL(KIND=8), INTENT(IN) :: A
              REAL(KIND=8), INTENT(IN) :: OMEGA
              REAL(KIND=8), INTENT(IN) :: AW(0:CRAMES%LENAW1-1)
              REAL(KIND=8), INTENT(OUT) :: I
              REAL(KIND=8), INTENT(OUT) :: ERR
              REAL(KIND=8), INTENT(IN) :: SIT
              REAL(KIND=8), INTENT(OUT) :: ANS(I_POINT)
            END SUBROUTINE INTDEO2_RECT
          END INTERFACE 
        END MODULE INTDEO2_RECT__genmod

Note the lack of INTENT on the args of the declaration of function F interface.

I cannot say if that contributes to the error message or not.

If I remove /warn:interfaces, the code runs properly (inspected with debugger, and results correct)

Jim Dempsey

[mecej4]

I have found the auto-generated INTENT(OUT) attribute to be a source of mischief when tied to array arguments and derived type arguments. The program that generated the interface may have determined that one or more array elements or derived type components appeared only to the left of an assignment, and concluded that INTENT(OUT) best matched the actual usage. Unfortunately, the rules of Fortran dictate that with INTENT(OUT) the entire array or derived type becomes undefined when the subprogram is entered, so every element or component has to be defined/redefined before subprogram exit, which is not the programmer's intent most of the time -- the programmer's intent may be stated as "value(s) not used, and some but not necessarily all elements/components may be changed".

The solution is to remove INTENT(OUT) from array and derived type dummy arguments.

[Steven_L_Intel1]

While the .f90 may not always be a faithful replica of the actual procedure's interface, and is just for your reference, this is indeed a bug. Escalated as issue DPD200371446.

[jimdempseyatthecove]

Ah, that is easy enough to do, will strongly document this as to what is going on. Thanks mecej4.

Steve, the removal of the INTENT(..)'s in the auto-generated module file may have been a work-around attempt to the problem mecej4 mentions.

Jim Dempsey

[Steven_L_Intel1]

We don't auto-generate INTENT. It's there only if you put it there yourself.

[Steven_L_Intel1]

I think this is fixed in 16.0. Let me know if this is not the case.