comparing F2C output to Sun Fortran output

[David G. Hough at validgh]

If you have occasion to compare Fortran outputs, you may be find the 
following README of interest:

=========================================================================

The accompanying codes modify F2C so that output of programs processed by F2C
is more like that of programs processed by Sun's Fortran 3.0 compiler.
There is about 80KB of code, available by email from dghavalidgh.com.

Like F2C, these modifications are provided free, with no guarantee that they
will be found useful for any particular purpose.   I developed them to
facilitate my testing of the GCC+F2C combination against Sun Fortran 3.0,
and I don't make any value judgments about which output formatting looks
better.

The usefulness of these modifications
may diminish with older or newer versions of Sun Fortran.
However knowing where to start hacking may expedite the work of others
who want to compare F2C to various Fortran compilers.

Persons comparing Fortran outputs should also know about spiff, a freely 
distributable replacement for diff that can be programmed to tolerate
minor numerical differences, by Daniel Nachbar at Bellcore.
It's included in the SPEC tools and is probably available elsewhere.

Contents of the _SUN_OUTPUT modifications to the F2C version of 3/94:

README

Replacement for f2c module:

io.c

Replacement for libf2c modules:

fmt.h
lio.h
close.c
dolio.c
err.c
ilnw.c
lwrite.c
s_stop.c
wref.c
wrtfmt.c
wsfe.c
wsle.c

If your version of F2C is up to date, the only differences should be
bracketed by #if preprocessor directives involving _SUN_OUTPUT.    If compiled
normally, results should be unchanged from the current F2C distribution.

If compiled with -D_SUN_OUTPUT, the output of programs compiled with f2c and
linked with libf2c will be more like that of programs compiled with
Sun Fortran 3.0 on SunOS 5.3.

The changes are intended to remove many differences with respect to blank
padding, decimal point position, zeros before the point, 
and number of places after the point.    Not all differences could be removed
with simple hacking; an example is list-directed output of numbers near
powers of ten; f2c invokes sprintf %g format and this particular difference
appears refractory, e.g.

        print *,1.0e2
        print *,1.0e3
        print *,1.0e4
        print *,1.0e5

yields

diff f77.output f2c.output

<     100.0000
<     1000.000
<     10000.00
<     100000.0
---
>      100.000
>      1000.00
>      10000.0
>      100000.

Furthermore, these changes do nothing to remove the causes of different
numbers being printed due to differences in expression evaluation and
in math library functions used (Sun Fortran uses single-precision versions
of elementary transcendental functions when arguments are single-precision;
F2C always promotes to double), nor do they address differences in output
caused by differences in base conversion routines.   F2C mostly relies on
the underlying sprintf implementation, while Sun Fortran calls directly the
lower-level functions invoked by sprintf.

Or at least it did when I worked on Sun libI77 several years ago.   That code
has passed through several hands since then, perhaps not always for the better;
I don't know the underlying cause of the peculiar magic constants in lio.h.  
In any case the changes in libf2c were derived by trial and error hacking,
and not by study of the Sun source code.

Special notes:

io.c is part of f2c rather than libf2c.   It is intended to work around a
bug in f2c I discovered in the course of this project whereby

        write(6,1)
 1      format('aa' 'bb')

produces a ^B in the middle of the output.   There may be a libf2c fix for
this bug, but I found this one in f2c quicker.

s_stop.c implements the STOP statement.   The output is more like Sun's,
but because F2C prints directly to stderr and Sun (I think) prints via 
Fortran unit 7, I couldn't get the output to show up in the same place
when stdout and stderr are directed to the same file.

close.c  contains f_exit which is called at the end of execution after a
stop, pause, signal, or exit from main.    If ONEXIT is defined in main, 
f_exit may be called more than once.     
The modifications are intended to call the
ieee_retrospective function that accompanies some versions of SunOS and
Sun compilers, with checking to avoid calling ieee_retrospective
more than once.