Fortran weirdness

Fortran weirdness

[Peter Stuge]

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

Re: Fortran weirdness

[Toon Moene]

Peter Stuge wrote:

> 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.

Yes, this is harmless ...

> 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.

Hmmm, you might want to try -Wuninitialized (on its own, combined with 
an optimisation level, because this analysis is only done when 
optimizing), i.e. g77 -O2 -Wuninitialized blah.f.

This might catch variables that are not initialised before use.

Another line of attack might be to compile with array bound checking on 
(the -fbounds-check option).  This tells you when the program tries to 
access arrays outside their declared bounds.

Please inform me of the results of the tests I indicated above; perhaps 
I can help further if this doesn't help.

Cheers,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

RE: Fortran weirdness

[Hillel (Sabba) Markowitz]

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