RE: Fortran weirdness

["Hillel (Sabba) Markowitz" <sabbahem at bcpl dot net>]

You should really install gcc-3.2 on your system.  This has the most up to 
date g77 available.  There are sufficient differences and problems that you 
should not run your test until gcc is updated.

One other point is to check if your workshop version was built in 64 bit mode.
 Linux only has a 32 bit mode.

One other point would be to build your application on Solaris using bothe 32 
bit (default or -m32) and 64 bit (-m64) modes using gcc-3.2  This can tell you 
a little more about what is going on if you run into problems.


--------------------- Original Message --------------------------------------
From: Peter Stuge <peter-gcc-help at flygp dot se>
     To: gcc-help at gcc dot gnu dot org
     Date: Wed, 13 Nov 2002 20:45:21 +0000
     Subject: Fortran weirdness

Hi!

We're in the process of migrating a few different platforms to Linux, one of
these platforms is Solaris, where we're currently running:

f77: WorkShop Compilers 5.0 98/12/15 FORTRAN 77 5.0

to compile 72k+112k lines of "legacy" (third-party) fortran code into object
files that are linked with in-house C code.  These binaries run fine.


On Linux, using g77 0.5.25 20010319 (prerelease) or 0.5.26 20020220 (release)
and gcc 2.95.4 20011002 (Debian prerelase), they don't.

Compilation goes fairly well, g77 just tells us this for one of the files:
--8<--
         DATA OPTLIS /SIZEOP * ENDLLI/
                      ^
Initialization of large (322350-unit) aggregate area `optlis' at (^)
currently very slow and takes lots of memory during g77 compile -- to be
improved in 0.6
-->8--
but this seems to be a matter of compilation time rather than actual errors
during compilation.

Unfortunately, when the program is run, we get into trouble.  The Fortran
code reads a couple of flatfile databases, using formatted READ()s in all
the right places, and our g77 compiled code on Linux ends up with NAN in a
certain position in an array where f77 compiled code on Solaris has 1006.83.

There are a bunch of other, just fine, values before our missing one that
very likely also originate from the textfile databases.

Any ideas as to why the g77 compiled code ends up with bad data?  Any more
information I can provide?

I've tried adding -fno-automatic -finit-local-zero -Wpedantic -Wsurprising
but all this gives is warnings about precedence for immediate negative
numbers and the gobs of unused variables in the code.  No difference at
runtime.

On both Linux and Solaris, we're using the Fortran compiler for linking.

Thanks in advance for any insight!


//Peter

--------------------------- End of original message 
---------------------------

-- 
Said the fox to the fish, "Join me ashore".
 The fish are the Jews, Torah is our water

Hillel (Sabba) Markowitz - sabbahem@bcpl.net