wrong entry in calling a DLL

[LRaim]

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.
 
 

[IanH]

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]

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]

ENTRY - Status: Declared obsolescent in Fortran 2008.

[LRaim]

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

[Kevin_D_Intel]

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