Detect How Pesky Customers Compiled the Code

[Nick2]

Actually sometimes it's pesky co-workers using the wrong compiler options...but either way, I wanted to come up with a way to make sure they compile the code with "Recursive" and "No Static Allocation" options, which I thought would work great with the following code. Unfortunately, when I compile with optimization, the piece of code does not do what it is intended (RECTESTA is pretty much completely bypassed).

Any idea how to determine if the code is compiled with Recursive functions enabled? Is this a bug with the optimization feature?

[cpp]      PROGRAM MAIN
      COMMON/EXPFIX/IBLNKG,IBLNKS,IDIAG,IERRX,ISTKSIZ,IFIRST
      IF(IFIRST.EQ.0)THEN
         CALL RECTESTA(0,6)
      ENDIF
      PRINT *,'GOOD'
      END


C
C
C***********************************************************************
C
      SUBROUTINE RECTESTA(INUM,IDIAG)
C This subroutine does a simple test to make sure our compiled
C executable can deal with recursive subroutine calls.  If not, we
C exit the code.
      IMPLICIT NONE
      INTEGER INUM, IDIAG, IDUM
      CHARACTER*100 TEMP
C
      IF (INUM .EQ. 0) THEN
       IDUM=10
       CALL RECTESTB(IDIAG)
       IF (IDUM .NE. 10) THEN
         TEMP='FATAL ERROR:  '
         CALL STROUT (IDIAG,TEMP)
         TEMP='The code may have been compiled with legacy options '//
     .        'such as static allocation of local variables.'
         CALL STROUT (IDIAG,TEMP)
         TEMP='In CVF 6.6 this is fixed by enabling recursive routines.'
         CALL STROUT (IDIAG,TEMP)
         TEMP='For other compilers, please see the '//
     .        'vendor-specific documentation.'
         CALL STROUT (IDIAG,TEMP)
         TEMP='Please contact XXX for further assistance.'
         CALL STROUT (IDIAG,TEMP)
         STOP
       ENDIF
      ELSE
       IDUM=20
      ENDIF
      RETURN
      END

C
C***********************************************************************
C
      SUBROUTINE RECTESTB(IDIAG)
C This subroutine is a helper for RECTESTA.  See RECTESTA.
      IMPLICIT NONE
      INTEGER IDIAG
C
      CALL RECTESTA(1, IDIAG)
      RETURN
      END


      SUBROUTINE STROUT (IUNT,STR)
C **********************************************************************
C
C     STROUT
C
C **********************************************************************
C WRITE STRING TO FILE IUNT
C
      CHARACTER*(*) STR
      INTEGER LENF
      IE= LEN_TRIM(STR)
      PRINT*, STR(1:IE)
 100  FORMAT(1X,A)
      RETURN
      END
[/cpp]

[Steven_L_Intel1 · Accepted solution]

First, why do you assume that IFIRST will be zero on entry to the program? There's no guarantee of that unless you have a BLOCK DATA subprogram somewhere to initialize it. What evidence do you have for a "bug in optimization"?

Why are you going through all this hassle? Just add the RECURSIVE keyword to your subroutines that need to be reentrant and it won't matter what the user says to compile.

I suspect that what happens is that the optimizer does enough inlining to do away with variable IDUM entirely. Since there is no place visible to the compiler between the assignment of IDUM and the test where the value could legally change, the optimizer assumes it hasn't changed and just "value replaces" the reference with 10.