topic wrong entry in calling a DLL in Intel® Fortran Compiler

wrong entry in calling a DLL

LRaim — Sun, 14 May 2017 13:47:08 GMT

I have recompiled (with IVF16, 64bits) a dll unchanged from about 2 years previously generated with IVF15 32 bits.
The export functions are entry points of the 'main subroutine' as follows:
=======================================================
      SUBROUTINE XSTUO_INIT(IHELP,IERR)
!+... ******************************************************************
. . . . . .
. . . . . .
. . . . . .
!
!...* export / import statements * ....
!
! Expose this subroutine to users of this DLL
!
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTUO_INIT
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTPRT_EXEC

!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_SNO
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_SLIST
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_SPROP
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_QTPV

!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_CPNO
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_CPKEYS
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_CPNAMES
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_MW
!DEC$ ATTRIBUTES     DLLEXPORT :: XSTGET_SDSIZE
!
!
!
      ENTRY   XSTPRT_EXEC(IVNAME,IERR)
!+... ******************************************************************

. . . . . . . .
. . . . . . . .

ENTRY XSTGET_QTPV(IVNAME,IOLEN,IOVALUE,IERR)
!+... ******************************************************************

==================================================================================

In the first test an exception was found. The DLL is called by a C++ application now in 64 bits mode.
By following the dll in debugging execution using VS one can see surprisingly that the initial call to
XSTUO_INIT(IHELP,IERR) enters the dll at XSTGET_QTPV which is the last entry in the source code.
Attached is the image of the VS debugging execution.

Maybe. There might also just

IanH — Sun, 14 May 2017 20:08:00 GMT

Maybe. There might also just be some confusion between the compiler and debugger around how the instruction pointer maps to line numbers. I'd trace the call from the C++ through to the Fortran in disassembled form to just confirm things first.

This is a compiler bug not

LRaim — Mon, 15 May 2017 10:27:11 GMT

This is a compiler bug not present in previous version.
By changing each entry into a separate subroutine the problem disappear.
It seems that regression tests on new versions of the compiler are not well performed.

ENTRY - Status: Declared

andrew_4619 — Mon, 15 May 2017 10:48:16 GMT

ENTRY - Status: Declared obsolescent in Fortran 2008.

I am waiting for comments

LRaim — Tue, 16 May 2017 14:33:21 GMT

I am waiting for comments from Intel people.
Have I to post the problem to premier support ?

I had checked w/Development

Kevin_D_Intel — Tue, 16 May 2017 14:42:52 GMT

I had checked w/Development and while what Andrew notes is true and that was included in our 16.0 User's guide, there was no change in the treatment of ENTRY, therefore, the change per the Fortran 2008 Standard is not a factor so we need to investigate this further.

Please do provide us with a complete reproducer and report this via our Online Service Center : http://www.intel.com/supporttickets

Thank you