Conference turris::fortran

1185.0. "/ANALYSIS qualifier infinate loop." by CSC32::EHA (Flip) Wed Feb 19 1997 12:58

    Hello,
    
    I have another nasty little compiler problem.  It seems there is a
    condition that causes the FORTRAN 77 V7.0-6 compiler to a bit of source
    code for more than 30 minutes of CPU time on the Alpha.  This seems
    strange, because changing a qualifier makes it compile in less than 30
    seconds.  
    
    I think that the cause of the problem comes from an include file
    including another include file and using the /ANALYSIS_DATA qualifier. 
    I have a example that shows the problem:
    
$ ver = f$verify(1)
$ on warning then goto clean_up
$!----------------------------------------------------------------------
$ create direct_test.for
      SUBROUTINE DIRECT_TEST
      IMPLICIT NONE
      INCLUDE 'DC9.P'
      INCLUDE 'DL9.P'
      INCLUDE 'DT9.P'
C
      INTEGER*4 I,J
C
      I = 2
      J = 3 * I
      RETURN
      END
$!----------------------------------------------------------------------
$ create test.for
      SUBROUTINE TEST
      IMPLICIT NONE
      INCLUDE 'IC9.P'
      INCLUDE 'IL9.P'
      INCLUDE 'IT9.P'
C
      INTEGER*4 I,J
C
      I = 2
      J = 3 * I
      RETURN
      END
$!----------------------------------------------------------------------
$ create test2.for
      SUBROUTINE TEST2
      IMPLICIT NONE
      INCLUDE 'IC9.P'
      INCLUDE 'IL9.P'
C
      INTEGER*4 I,J
C
      I = 2
      J = 3 * I
      RETURN
      END
$!----------------------------------------------------------------------
$ create dl9.p
      CHARACTER*16  A9LIMITS
      PARAMETER( A9LIMITS = '1994120101')
$!----------------------------------------------------------------------
$ create dc9.p
      CHARACTER*16 A9CODES
      PARAMETER( A9CODES = '1994050701')
$!----------------------------------------------------------------------
$ create dt9.p
      CHARACTER*16 A9TFCOM
      PARAMETER( A9TFCOM = '1988010101' )
$!----------------------------------------------------------------------
$ create ic9.p
      INCLUDE 'DC9.P'
$!----------------------------------------------------------------------
$ create il9.p
      INCLUDE 'DL9.P'
$!----------------------------------------------------------------------
$ create it9.p
      INCLUDE 'DT9.P'
$!----------------------------------------------------------------------
$!
$!	Typical use of includes with direct inclusion
$ FORTRAN/ANALY DIRECT_TEST.FOR
$!
$!	Atypical use of two includes referring to other includes
$ FORTRAN/ANALY TEST2.FOR
$!
$!	Atypical use of three includes referring to other includes.
$!	The /ANALYSIS option is not specified.
$ FORTRAN TEST.FOR
$!
$!	Atypical use of three includes referring to other includes.
$!	The /ANALYSIS option is specified.  The command does not finish...
$ FORTRAN/ANALY TEST.FOR
$!
$clean_up:
$ ver = f$verify(ver)
    
    Thank you!
    Al Eha
    Digital customer Support

    	I can reproduce this readily using recent sources.  It's
    a bug, and I'm looking at it now.
    
    	Thanks for the simple example!
    
    Cheers!
    Dave Eklund
    

    	Fixed by edit 4-117.  This was an interesting bug,
    only happening when you exit a pair of include files at
    the "same" time, and then reach the same level again.
    An internal stack was not being maintained properly,
    resulting in the looping you witnessed.  This only
    happens when using /ANALY.  Thanks again for the
    simple example!
    
    Cheers!
    Dave Eklund
    

    Hello,
    
    I feel stupid to ask this, but I am not sure what edit 4-117, refered
    to in .2, is?  Is this part of a patch?
    
    Thanx!
    Al
    

Edit 4-117 is the way we identify the fix internally.  When a new kit is
announced {ssb, eco, field test, etc}, it has a version number that looks
like lv.m-nnn-gggg:

	l	is a letter:	V == ssb release
				T == field test
				X == development {"hot"}

	v	is the major version number, eg, DF on Alpha/Uinx is version 4
	m	is the minor version number, eg, DF on Alpha/Uinx is version 4.1
	nnn	is the edit number
	gggg	is the GEM {backend} baselevel

If the "nnn" is greater than or equal to 117, then that kit contains edit 117
and therefore fixes this bug.

Your next question is, when will a kit with edit 117 show up?  I don't know
exactly.  We just did v4.1 on Au and v7.1 on AV so I'd like to wait until
at least April-1997 to do ECO kits... if something ugly happens before then,
we'll do it earlier.

If you are in desparate need of an edit, please send me mail and we might be
able to give you a "hot" compiler that fixes the problem.  This falls into the
"whatever it takes" category - but there are strings attached so be careful
what you ask for.

/Stan

    Stan,
    
    Thank you for the information.  It's good to learn something new each
    day, but I have to be very carefull not to learn too much. ;-)
    
    I suggested  a workaround of adding a comment statement at the end of
    the include files.  This seems to work for the test case I sent. 
    Hopefully this will work in all cases.
    
    Thanx!
    Al