Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
19 Views

wrong entry in calling a DLL

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.
 
 
0 Kudos
5 Replies
Highlighted
Black Belt
19 Views

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.

0 Kudos
Highlighted
New Contributor I
19 Views

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.

 

 

 

0 Kudos
Highlighted
Valued Contributor III
19 Views

ENTRY - Status: Declared obsolescent in Fortran 2008.

0 Kudos
Highlighted
New Contributor I
19 Views

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

0 Kudos
Highlighted
Employee
19 Views

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

0 Kudos