Linking error

[Dishaw__Jim]

When the calling convention is set to "CVF" and you have a program of the form below, the link fails with an external symbol not found error. If the calling convention is set to "Default" no such error occurs. Is this the correct behaviour or a bug?

PROGRAM test
USE stuff
IMPLICIT NONE

! Variables
INTEGER :: flag

IF (flag .EQ. 1) THEN
CALL do_something(method_a)
ELSE
CALL do_something(method_b)
END IF

CONTAINS
SUBROUTINE method_a(i)
INTEGER, INTENT(IN) :: i

WRITE(*,*) 'Hello world ', i

END SUBROUTINE method_a

SUBROUTINE method_b(i)
INTEGER, INTENT(IN) :: i

WRITE(*,*) 'Goodbye world ', i

END SUBROUTINE method_b
END PROGRAM test

MODULE stuff
IMPLICIT NONE

PRIVATE
PUBLIC :: do_something

CONTAINS

SUBROUTINE do_something(method)

INTERFACE
SUBROUTINE method(i)
IMPLICIT NONE

INTEGER, INTENT(IN) :: i
END SUBROUTINE method
END INTERFACE

CALL method(47)
END SUBROUTINE do_something
END MODULE

[Jugoslav_Dujic]

Which unresolved symbols?

Jugoslav

[Steven_L_Intel1]

I don't see any linking errors when building that source with /iface:cvf and 9.0.028. I did have to put the module first in the source.

[Dishaw__Jim]

I should have mentioned that the program and module are in seperate files.

The error message was

test.obj : error LNK2019: unresolved external symbol _TEST._METHOD_A referenced in function _MAIN__


The irony of such a message is that method_a is defined in test.

[Dishaw__Jim]

The version I am using is 9.0.018 Build 20050430

[Steven_L_Intel1]

That's from nine months ago. Please download and install 9.0.028, the current version, and try again.

[Dishaw__Jim]

I downloaded and installed the 028 Build 20051130 version and got the same unresolved external symbol error when using /iface:cvf

[Steven_L_Intel1]

Then it would seem the source you are using is different from the one posted. Please submit an issue to Intel Premier Support and attach the actual source you are using. We'll be glad to investigate.

[Dishaw__Jim]

Well I submitted the bug report, but I don't think the customer support person quite understood the problem. The essence of the response was



"I investigated your case and I believe that this is not a compiler bug, these link errors occur only when we set the calling convention as STDCALL & CVF but not with STDREF,CREF & Default. below is the description for this.



The /iface:stdcall and /iface:cvf options cause the routine compiled and routines that are called to have a @ appended to the external symbol name, where n is the number of bytes of all parameters. Both options assume that any routine called from a Fortran routine compiled this way will do its own stack cleanup."



The problem, as I see it, is how the compiler is generating names. There are two files, console1.f90 and source1.f90. When I use the /iface:cvf option, I see the symbols _CONSOLE1.METHOD_A, _CONSOLE1.METHOD_A@4, _CONSOLE1.METHOD_B, and _CONSOLE1.METHOD_B@4 in the console1 object file. The _CONSOLE1.METHOD_A and _CONSOLE1.METHOD_B are flagged as unknown symbols in the context of the console1 object file. If I use the /iface:default option, the @4 names are gone and there are no unknown symbols. I think this is a compiler problem since it is generating names inconsistently and the linker cannot resolve them.

[Steven_L_Intel1]

The engineer who took your issue asked me about it this morning. When I saw the whole source I recognized it. It is a compiler bug which occurs when you pass a contained or module procedure as an actual argument and are using /iface:cvf. If you look carefully at the linker errors, you will note that the missing symbols seem to have extra blanks at the end, and in fact they do. The compiler is supposed to fill those in with the proper STDCALL decoration or trim them, but it isn't. We're working on it. If you can switch to the default calling convention that would be the easiest workaround.

[Dishaw__Jim]

Thanks--fortunately this was never a real issue for me. I stumbled on it when I imported a CVF workspace (which turns on /iface:cvf by default) and couldn't figuure out why the code did not compile. After I figured out the problem, I figured I should report it as a bug. Since I don't have any legacy CVF libraries that I use, this bug wasn't a serious for me.