[beebe@math.utah.edu: Problems with g77 (GNU and egcs) and assigned GOTO]

[craig at jcb-sc dot com]

------- Start of forwarded message -------
X-POP3-Rcpt: burley@mescaline.gnu.org
Date: Mon, 15 Mar 1999 08:00:42 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: burley@gnu.org, rth@cygnus.com
Cc: beebe@math.utah.edu, "J. W. Mintmire" <mintmire@alumina.nrl.navy.mil>
X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322
        INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT
        84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Problems with g77 (GNU and egcs) and assigned GOTO

I'm working on porting my PLOT79 graphics system to GNU/Linux 2.0.35,
from a recent Redhat distribution.  This system is venerable (it is
based on the 1979 SIGGRAPH CORE proposal, whence the name PLOT79),
with some code dating from the early to mid 1970s. It is also large:
here is a recent line count summary:

        PLOT79                  Assembly          2,248
                                C                63,491
                                SFTRAN3         170,503
                                Fortran         270,355
                                total           506,597

It has run on many Fortran systems, including IBM MVS, Univac, Wang,
CDC, DEC 20, VAX, and UNIX variants from DEC, HP, IBM (RT, RS/6000,
and 3090), SGI, and Sun, and the code has been stable for about 15
years.

The SFTRAN3 code uses a preprocessor developed at the Jet Propulsion
Laboratory in Pasadena in the 1970s, and used at that time for a lot
of the JPL interplanetary probe software.  

An important feature of SFTRAN3 is the use of remote code blocks which
look something like this:

	DO (Get Next Item and Process It)
	...

	PROCEDURE (Get Next Item and Process It)
	...
	END PROCEDURE

They are translated to Fortran code like this:

C	DO (Get Next Item and Process It)
	ASSIGN 20001 TO NPR001
	GOTO 30001
20001   ...

	...

C	PROCEDURE (Get Next Item and Process It) 	      
30001	...
	GO TO NPR001, (20001, 20017, 20031, ...)


To my great surprise, this does not work properly on GNU/Linux 2.0.35.

My first attempt used the native g77 installation on that system,
which reports

% /usr/bin/g77 --version
egcs-2.90.27 980315 (egcs-1.0.2 release)

While the SFTRAN3 processor built with that compiler, there were other
parts of the PLOT79 code that failed, and gdb sessions showed the
failure was always because of a garbage address in an assigned goto
variable.

On Saturday, I therefore fetched the latest gcc release (2.8.1) from
ftp://prep.ai.mit.edu/pub/gnu/gcc, and installed it with "./configure
&& make bootstrap install", and then did a rebuild of PLOT79 with the
new g77 2.8.1 compiler.  While the build succeeded, some of the built
programs failed as before, and at exactly the same places.

I therefore checked the Cygnus site, and late Saturday, downloaded and
installed the latest release, egcs-1.1.1, again using "./configure
&& make bootstrap install".  The newly-installed g77 reports

% /usr/local/bin/g77  --version
GNU Fortran 0.5.24-19980804

This version is even worse than before: now the SFTRAN3 processor
(which is itself written in SFTRAN3) builds, but fails on a trivial
test.  Here is a fragment of a gdb session:

(gdb) n
398           ASSIGN 20047 TO NPR007
(gdb) n
399           GO TO 30007
(gdb) p npr007
$6 = 1
(gdb) n
357     30007 IF (NFILL.GT.0) CALL F4MVC(BLANKS,1,OUTBUF,NOUT+1,NFILL)
(gdb) n
358           NOUT = NOUT+NFILL
(gdb) n
359           GO TO NPR007, (20045,20046,20047)
(gdb) n
Cannot insert breakpoint 0:
Temporarily disabling shared library breakpoints:
0 

Program received signal SIGSEGV, Segmentation fault.
0x2e in ?? ()
(gdb) p npr007
No symbol "npr007" in current context.

Once again, the failure is in the use of an assigned goto variable.
Notice the peculiar value, 1, for that variable (NPR007).  In other
failures of this type, gdb has shown very large (e.g., 0x3f800000)
values in the assigned goto variable causing the failure.

Curiously, in each of these failures, there have been a great many
successful uses of assigned goto before the failure.

Indeed, this simple test produces the expected output:

% cat assigned-goto.f 
      integer ngoto
      assign 10 to ngoto
      go to 99
   10 print *, 'Got back okay to 10'
      assign 20 to ngoto
      go to 99
   20 print *, 'Got back okay to 20'
      assign 30 to ngoto
      go to 99
   30 print *, 'Got back okay to 30'
      print *, 'Test of assigned GOTO passed'
      stop
   99 goto ngoto,(10,20,30)
      end

% g77 assigned-goto.f && ./a.out
 Got back okay to 10
 Got back okay to 20
 Got back okay to 30
 Test of assigned GOTO passed

So, have you folks ever had problem reports with g77 due to assigned
gotos that might uncover a solution to this problem?

Right now, I'm stalled in my porting attempts, and cannot proceed
until I get a working Fortran 77 compiler on GNU/Linux, and as far as
I know, g77 is the only one available.

I don't have g77 installed on any of my other UNIX architectures, but
I'm going to do a build on Sun Solaris 2.6 shortly of the egcs-1.1.1
release, since that appears to be newest.  If the problem goes away
with the SFTRAN3 processor, and PLOT79 builds and tests successfully,
then the finger would be pointed at the Intel x86 code generator in
the g77/gcc backend.  However, if the problem persists, then it is
more likely in intermediate code.

Because of the large number of radically different architectures and
operating systems that PLOT79 has been installed on, I very much doubt
that the problem lies in its Fortran code, but much more likely, in
the Fortran compiler.

- -------------------------------------------------------------------------------
- - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- - Center for Scientific Computing       FAX: +1 801 585 1640, +1 801 581 4148 -
- - University of Utah                    Internet e-mail: beebe@math.utah.edu  -
- - Department of Mathematics, 322 INSCC                   beebe@acm.org        -
- - 155 S 1400 E RM 233                                    beebe@ieee.org       -
- - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  - 
- -------------------------------------------------------------------------------
------- End of forwarded message -------