Call to ENTRY statement fails to return

agoverdhan · ‎08-20-2006

The following code fails to return to the main program following a call to an ENTRY statement. CVF calling convention... obviously this code snippet does not do anything useful other than illustrate the issue. It works with the DEBUGbuild but not for RELEASE build setting. Also works with DEFAULT calling convention and RELEASE build. Can anybody confirm if this is correct and a known issue?

TIA

--arvind

PROGRAM TESTENTRY

      COMMON/TAPE/ MINP,MOUT,MERR,NTP(13),NRP(13),NTR(13)      MINP=5      MOUT=6
      IFIL=11
      write(6,*) "pre call",IFIL      CALL SDBF_CTL_SDB5(IFIL)      write(6,*) "post call",IFIL ! DOES NOT RETURN HERE w/ CVF
  990 CONTINUE      stop      END      SUBROUTINE SDBF_CTL_SDB4      COMMON /TAPE/ MINP,MOUT,MERR,NTP(13),NRP(13),NTR(13)      CHARACTER*132 C132      IFIL=MINP      GO TO 10*-----alternate entry point      ENTRY SDBF_CTL_SDB5(JFIL)      IFIL=JFIL   10 CONTINUE      IF(IFIL.EQ.MINP) THEN        WRITE(6,1000)      ELSE        WRITE(6,1001)      ENDIF 1000 FORMAT(1X,'ifil.eq.minp') 1001 format(1x,'ifil.ne.minp')      RETURN      END
Using the complier:

Intel Fortran Compiler for 32-bit applications, Version 9.1 Build 20060706Z Package ID: W_FC_C_9.1.028

grg99 · ‎08-21-2006

Sorry to be a poop, but you can fix this in several ways with minor changes to the code:

(1) Don't use ENTRY-- it's old and as you have seen, prone to cause usr and compiler errors, plus I think it's been deprecated for years.

(2) Instead use a wrapper routine, very simple one that just does a CALL LOWER(5), or CALL LOWER(6), no jumps or entries needed.

(3) The problem may involve having a different number of parameters-- some calling modes may not like that. You could add a unused parameter to the one without any parameters (Which eliminates the convenience of this whole concept), OR you could make the parameter OPTIONAL, and defaulting to = 5, one of the newer fortran features.

----

In other words, work around the problem, or use cleaner code, instead of edxpecting the compiler to get fixed for this one strange bit of code.

( I know, it probaby SHOULD work, but do you want to be right in your indignation, or have a program that works?) :)

Steven_L_Intel1 · ‎08-21-2006

Well, I'll be a poop too, but in the other direction. ENTRY is not deprecated, and this ought to work. In fact it does, unless you ask for optimization. I will pass this on to the developers. I'd ask that you file a support request to Intel Premier Support and attach the code sample. When you do so, please reference T70018. The stack is not getting properly restored on exit of the subroutine.

agoverdhan · ‎08-21-2006

Steve, I shall do as you suggest and file a request to Support.

grg99, The "fix" was already taken care of before posting here.

--arvind