Problems with replacing statement functions

Problems with replacing statement functions


I am modernizing legacy code, replacing statement functions through internal functions. While compiling the files individually no error occurs. If I am trying to rebuild the project or compile them all together I am getting link error lnk2019 and lnk1120, telling me the subroutine above calling the subroutine test1 containing the internal function can not link.

If I am using the statement function everything works fine...

Here are the code snippets:

subroutine test1 (..., xk, ... )

use Flowfield_size_control_mod, only : KX, LX, IORD, KXMAX, KXIMAX,  LXMAX, LXIMAX
use Precision_mod,              only : DP

implicit none

![ code ]

dimension ::  xk ( -IORD: KXIMAX,  -IORD : LXIMAX )
dimension :: xkth ( 0 : KXMAX, 0 : LXMAX )

real ( kind = DP ) :: xk, xkth

! old statement function
! ABL(XM2,XM1,X,XP1,XP2)=(XM2-8.D0*XM1+8.D0*XP1-XP2)/12.D0

![ code ]

DO 52 L=0,LX                                                           
DO 53 K=0,KX                                                           
53 END DO                                                                             
52 END DO  

![ code ]

! new internal function
   real ( kind = DP ) function abl ( xm2, xm1, x, xp1, xp2 ) result ( ret_val )
        implicit none
        real ( kind = DP ), intent ( in ) :: xm2, xm1, x, xp1, xp2  
        real ( kind = DP ) :: ret_val

        ret_val = ( xm2 - 8.0_DP * xm1 + 8.0_DP * xp1 - xp2 ) / 12.0_DP

    end real function abl  
end subroutine test1


 Any ideas?


Kind regards,


8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I don't see anything wildly obvious in the code snippet you showed, but there are few more pieces of data that might be helpful.
You said there were link-time errors -- what were the undefined names? Is it possible there was something else going awry?
Are you trying to access the contained routine ABL from outside of SUBROUTINE TEST1? that's not possible; its scope is only the current containing routine.
Any more details would be helpful!

Hi Lorri,

from my point of view the function is not called from the outside / there is no other function abl called in the project. I even tried placing the function in a module and provide it as an external function with the same result. Init.f90 is the subroutine calling test1.f90.

link errors are:

error LNK2019: unresolved external symbol "_test1" in function "_init".    init.obj    
fatal error LNK1120: 1 unresolved external    Debug\project.exe    

Due to the fact, that I am a newbie with ifort, I weren't able to extract more detailed error messages at the moment. Respectively I don't see why the subroutine stays unresolved, when I am replacing the statement function and leave the rest unchanged.

By the way I am using Intel(R) Visual Fortran Compiler XE [IA-32]. Thanks for the help! -- Martin




I fleshed out the code fragment that you posted into a compilable program and had no problems compiling and linking the two files with the version of IFort that you listed.

Please provide a complete example that exhibits failure to link.


Downloadapplication/octet-stream martin.f90405 bytes
Downloadapplication/octet-stream martinsub.f90927 bytes

Martin, thank you so much for this info. I may have an idea or two.

Did you cut-and-paste this message exactly, or re-type it yourself?

I ask because the Visual Fortran Windows default for external names is to uppercase the names, and you have lowercase names here.

Please check the project Properties, in particular Fortran->External Procedures->Name Case interpretation and make sure that it is consistent, and not accidentally changed for one source file in the project (causing the inconsistency).

Finally, please make sure you are linking against the object file created for "test1".

if this doesn't help, please do a clean-rebuild, and attach the build log, which might give more clues.


@ mecej4: You're right, your rebuild works fine on my system as well in the mentioned version. Kind of funny is, that I don't get the error with Intel(R) Visual Fortran Compiler XE [IA-32], however several other link errors, which were not there before. I'll post some code right after I checked some other issues. I don't want you wasting your time... Thanks a already!

@ Lorri: This one goes on me. I re-typed and translated it, because my versions aren't talking english. I'll check on the properties and do as you suggest. Thanks a lot for support and the help!

If there are still difficulties I'll write again.



an update to Intel(R) Visual Fortran Compiler XE [IA-32] and a clean re-build of the project did the job. Also the compiler doesn't like the double declaration of ret_val in the function declaration and inside the function itself.

Thanks to all for the help and the support.


Glad to hear you're up and running - good luck with the modernization effort.


Leave a Comment

Please sign in to add a comment. Not a member? Join today