Error #6897

[Sudhir1]

Hi All

I am trying to convert my Fortran subroutine from intel fortran 11.0.72 to OneAPI comiler and getting following error

error #6897: An interface-block in a subprogram must not contain an interface-body for a procedure defined by that subprogram

Could you please help with this

Thanks & Regards
Sudhir

[mecej4]

If your Fortran code is correct, it should be compilable by either of the versions that you mentioned. In other words, no conversion should be needed.

Interfaces bodies to the containing subprogram (i.e., interfaces-to-self), are not allowed. The F2008 standard contains this rule:

An interface body cannot be used to describe the interface of an internal procedure, a module procedure that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit. However, the name of a procedure may appear in a PROCEDURE statement in an interface block (12.4.3.2).

Please show the source code of a representative subprogram and a contained interface body in your program, and state the compiler options that you used.

[Sudhir1]

Thanks 

interf.f90 contains below

interface
FUNCTION SINVERSE(alpha,beta,gamma)
! IMPLICIT NONE
DOUBLE PRECISION SINVERSE(3,3),alpha,beta,gamma
END FUNCTION SINVERSE
end interface

Function contains below

FUNCTION SINVERSE(alpha,beta,gamma)

IMPLICIT NONE

INCLUDE 'INTERF.F90'

DOUBLE PRECISION S(3,3),SINVERSE(3,3),alpha,beta,gamma

DOUBLE PRECISION PI,g

COMMON/CONSTANT1/PI,g

SINVERSE=0.0D0; S=0.0D0;

! CHECK, IF ANGLES HAVE PI/2

if(abs(alpha-pi/2).le.1.0E-06)then

print*,'(alpha is near pi/2, process failed)'

return

endif

if(abs(beta-pi/2).le.1.0E-06)then

print*,'(beta is near pi/2, process failed)'

return

endif

if(abs(gamma-pi/2).le.1.0E-06)then

print*,'(gamma is near pi/2, process failed)'

return

endif

! MATRIX 'S'

S(1,1)=cos(beta)*cos(gamma); S(1,2)=sin(gamma); S(1,3)=0.0D0;
S(2,1)=-cos(beta)*sin(gamma); S(2,2)=cos(gamma); S(2,3)=0.0D0;
S(3,1)=sin(beta); S(3,2)=0.0D0; S(3,3)=1.0D0;

! INVERSE OF MATRIX 'S'

SINVERSE=FINDInv(S,3)

End FUNCTION SINVERSE

Thanks & Regards

Sudhir

[jimdempseyatthecove]

! YourUtilities.f90
module YourUtilities
! declare parameters and variables here
DOUBLE PRECISION, PARAMETER :: PI = 3.1415926535897932384626433_D0
DOUBLE PRECISION, PARAMETER :: g = 6.67430_D-11 ! m3.kg-1.s-2
...
contains
! module contained procedures here

FUNCTION SINVERSE(alpha,beta,gamma)
  DOUBLE PRECISION S(3,3),SINVERSE(3,3),alpha,beta,gamma
  SINVERSE=0.0D0; S=0.0D0;

  ! CHECK, IF ANGLES HAVE PI/2
  if(abs(alpha-pi/2).le.1.0E-06)then
    print*,'(alpha is near pi/2, process failed)'
    return
  endif
  if(abs(beta-pi/2).le.1.0E-06)then
    print*,'(beta is near pi/2, process failed)'
    return
  endif
  if(abs(gamma-pi/2).le.1.0E-06)then
    print*,'(gamma is near pi/2, process failed)'
    return
  endif
  ! MATRIX 'S'
  S(1,1)=cos(beta)*cos(gamma); S(1,2)=sin(gamma); S(1,3)=0.0D0;
  S(2,1)=-cos(beta)*sin(gamma); S(2,2)=cos(gamma); S(2,3)=0.0D0;
  S(3,1)=sin(beta); S(3,2)=0.0D0; S(3,3)=1.0D0;
  ! INVERSE OF MATRIX 'S'
  SINVERSE=FINDInv(S,3)
End FUNCTION SINVERSE
! other procedures follow (e.g. FINDInv, ...
end module YourUtilities

You would then would not use "INCLUDE 'INTERF.F90'" but instead use "USE YourUtilities" (no quotes).

You would likely not use a single large module with everything but rather use categories.

parameters that likely will never change (PI, G, etc...)

global variables

category group variables

category procedures (math, physics, statistical,, user interface, etc)

Note, to aid in transition, you might create modules to replace your named COMMONs using the same or similar name which works fine as long as all uses of the common map the same variable names and types.

Jim Dempsey

[andrew_4619]

The include file puts the interface  inside the routine, as said above "interface to self" is not allowed. That interface to an "external" subroutine should only be used in routines that call that subroutine. The code is not valid code remove the line "INCLUDE 'INTERF.F90'"

[mecej4]

As noted earlier, the interface block in the included file is not allowed. Nor does it serve any purpose in the body of SINVERSE.

On the other hand, you need to specify that FINDINV is DOUBLE PRECISION and DIMENSION(3,3). If you have IMPLICIT NONE in effect, even the old compiler would have flagged this error.

[Sudhir1]

Thanks It solved compilation issue but giving a message " Unhandled exception at 0x00A56B3C in exe file "w hile running 

FORTRAN severe (157): Program Exception - access violation

Could you please help me on this.

Thanks & Regards

Sudhir

[jimdempseyatthecove]

Access violation is caused by dereferencing an undefined reference. Or indexing an array (way) out of bounds to a point of being beyond virtual memory and/or to a protected memory page (typically page 0, execute-only page, and/or page requiring elevated privileges).

IOW you have a bug in your program and you need to debug to find the cause.

Jim Dempsey

[Sudhir1]

Thanks 

The programme was successfully compiled and run using Intel Fortran 11.0.72 +VS2008

when i converted it to intel OneAPI + VS2019 it doesn't give compilation error but throws below message while running

Any help on this

Thanks & Regards

Sudhir

[jimdempseyatthecove]

>> ... OneAPI + VS2019 it doesn't give compilation error but throws below message while running

Try using the ifort classic that came with the OneAPI download. The two compilers have different code bases.

If that fails too, then this may be indicative of your Intel Fortran 11.0.72 having a bug that happened to be benign.

Was your old build 32-bit and now your new build 64-bit?

Now that you have trace back information, it is likely that AXISTRANSFERV is being passed in bad arguments. If this is not found on first call, then you may need to insert some code in AXISTRANSFERV to perform sanity checks (typically called ASSERT(...) in C++). Once you find this bug, you may find yourself having a "How did this ever run?" moment.

Jim Dempsey

[mecej4]

There is no general solution for access violations. As you have been already advised, access violation is a symptom and the causes are many. There are several techniques that one can use and there are compiler options that can help detect bugs. If you do not already know how to do this, you will need to learn, and doing so will take time and patience.

In this case, the fact that compiling with Ifort 11.0.72 allows complete runs with apparently no errors is good news.

If you can provide the full source code + include files + data files + instructions to build and run, someone here may be willing to help. Put all  that into a zip file, upload the zip file to the cloud (such as Dropbox, GoogleDrive, OneDrive, etc.) and post a link to that here.