Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

wrong entry in calling a DLL

LRaim
New Contributor I
138 Views
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
IanH
Black Belt
138 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.

LRaim
New Contributor I
138 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.

 

 

 

andrew_4619
Honored Contributor I
138 Views

ENTRY - Status: Declared obsolescent in Fortran 2008.

LRaim
New Contributor I
138 Views

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

Kevin_D_Intel
Employee
138 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

Reply