Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29008 Discussions

Call statement invoking function as subroutine

DavidWhite
Valued Contributor II
1,196 Views

Can anyone explain why this happens?

If I use the option /warn: interfaces I get the following error for each call in my project.PSAT is not declared anywhere else in solution. There are no interfaces declared in the project. PSAT is a LIB project which is included in the solution to create a DLL. All arguments are declared explicitly in the calling routine (F90) and implicitly in the called routine (legacy F77 code).

Error: The CALL statement is invoking a function subprogram as a subroutine. [PSAT]

In DLL project ...

call

psat(tempk, pvap, rhol, rhov, iwork, propr, ierr)

TEMPK, PVAP, RHOL, RHOV all declared as REAL(KIND=8)

IWORK(NPROP) is INTEGER

INCLUDE 'nprop.cmn' defines NPROPas INTEGER, PARAMETER with value 43

PROPR(NPROP) is REAL(KIND=8)

InLIB project ...

SUBROUTINE PSAT(TK, PMPA, RHOL, RHOV, IWORK, PROPR, IERR)

with declares

IMPLICIT DOUBLE PRECISION (A-H,O-Z)

INCLUDE 'nprop.cmn'

DIMENSION PROPR(NPROP)

DIMENSION IWORK(NPROP)

Any ideas? Thanks.

0 Kudos
7 Replies
Steven_L_Intel1
Employee
1,196 Views
I think we'd need to see a buildable example that shows the problem. Please submit one to Intel Premier Support.
0 Kudos
jond
Novice
1,196 Views
Hello,

Has this issue been resolved? I am having the same error when calling a subroutine located in a LIB file. Is this a bug in the compiler or can the problem be resolved using compiler switches?

Thanks,
Jon
0 Kudos
Steven_L_Intel1
Employee
1,196 Views
I didn't see the problem report come in (doesn't mean it didn't, just that I didn't see it), and have not heard that there is an actual bug here. I could imagine this error being given if the subroutine name was given a type.

If you are having a problem, please submit a test case to Intel Premier Support so that it can be investigated.
0 Kudos
DavidWhite
Valued Contributor II
1,196 Views

I am now unable to replicate this error. Updates to both hardware and software probably make it impossible to verify now.

Thanks,

David White

0 Kudos
rwg
Novice
1,196 Views
I get this error message when I have two module definitions for the same subroutine.

My way to reproduce it: I have source file test.f containing subroutine test and compile it with switches /genmod and /module:"c:/moduledir" which produces test_genmod.mod test_genmod.f90 ind:/moduledir. I also have afile test_genmod.f90 in my project which contains a module with an interface for test like this:

MODULE TEST__genmod
INTERFACE TEST
SUBROUTINE TEST_1(...
!DEC$ ATTRIBUTES DECORATE,ALIAS:"TEST" ::TEST_1
...
END SUBROUTINE TEST_1
SUBROUTINE TEST_2(...
!DEC$ ATTRIBUTES DECORATE,ALIAS:"TEST" ::TEST_2
...
END SUBROUTINE TEST_2
END INTERFACE
END MODULE TEST__genmod

(Yes, that's a little bit insane, but that's the way you can reproduce it)

This produces file test_genmod.mod in my intermediate directory. Now, when I try to compile a program which calls subroutine test I get the error message:
error #6552: The CALL statement is invoking a function subprogram as a subroutine. [TEST]

Removing c:\moduledir\test_genmod.f90 and c:\moduledir\test_genmod.mod solves the problem. But if you recompiling test.f with switch /genmod this error message apears again because c:\module\test_genmod.f90 and c:\moduledir\test_genmod.mod are recreated.

So if you get this error message look for dublicate module definitions.
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,196 Views
David,

Is PSTAT declared elsewhere in any library?

Try declaring subroutine PSTAT with an interface

Note you have IMPLICIT DOUBLE PRECISION (A-H,O-Z)

Meaning PSTAT might be interpreted as a function returning DOUBLE or array of DOUBLES

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,196 Views
Also note

In your application the args you pass are declared as REAL(KIND=8) and in the subroutine you use IMPLICIT DOUBLE PRECISION(A-H,O-Z)

While REAL(KIND=8) and DOUBLE PRECISION are equivilent using today's compiler, these are not assured to be equivilent using tomorrow's compiler (future compiler might treat DOUBLE PRECISION equivilent to KIND larger than 8).

You may have a future issue lurking about.

And if the same INTERFACE (from a USE module) is used, this will enforce you to use the same declaration for both the caller and callee.

Jim Dempsey
0 Kudos
Reply