F2C modifications to produce output more like Sun Fortran 
Author Message
 F2C modifications to produce output more like Sun Fortran

If you have occasion to compare fortran outputs, you may 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.

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

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.
However spiff doesn't take care of problems caused by differences in list-
directed output implementations that cause line breaks to occur at
different places in long output lines.

Contents of the _SUN_OUTPUT modifications to the F2C version of 6 June 94:



Replacement for libf2c modules:


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 should 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 to simple hacking, e.g.

        print *,1.0e2
        print *,1.0e5


diff f77.output f2c.output

<     100.0000
<     100000.0

>      100.000
>      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 any justification for 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:

s_stop.c implements the STOP statement.   The output is more like Sun's,
but 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.
The modifications are intended to call the
ieee_retrospective function that accompanies some versions of SunOS and
Sun compilers.

test.f is a collection of test cases where Sun Fortran and unmodified F2C work
differently.    With Sun C 3.0, linking with -xlibmieee, the modified
differences are as follows, indicating some things I did not attempt to fix:

<     100.0000
<     1000.000
<     10000.00
<     100000.0

>      100.000
>      1000.00
>      10000.0
>      100000.

<     10000000.0000000
<     100000000.000000
<     1000000000.00000
<     10000000000.0000
<     100000000000.000
<     1000000000000.00
<     10000000000000.0
>      10000000.000000
>      100000000.00000
>      1000000000.0000
>      10000000000.000
>      100000000000.00
>      1000000000000.0
>      10000000000000.

<  ?    3828.52 <    100000.0?
<  ?    3.06266E-03 <    100.0000?
>  ?    3828.52 <     100000.?
>  ?    3.06266E-03 <     100.000?

<     -1.79769E+37 -Inf           -NaN          ?
>     -1.79769E+37 -Inf           NaN           ?


Consultant on system correctness, performance evaluation, and
IEEE 754 binary floating-point arithmetic --- Send for business announcement

Mon, 02 Dec 1996 03:19:07 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Sun compiler not liking X in format statements

2. Sun Fortran 1.4 vs. Sun Fortran 2.0

3. Sun Fortran output trouble

4. Why doesn't f2c produce printf?

5. Sun F90 (v1.1) produces huge objects

6. Wanted: Pascal Compiler Producing Interpretable Output

7. Salford95 and Lahey-Fujitsu Compiler producing different output with same program

8. Embedded TCL in JSP produces no output using BSF

9. clock format %Z option produces verbose output

10. Q:[F90][SUN] Compilation Problem with Sun Fortran 90 1.2

11. Need help with f2c on Sun

12. f2c -- Readable C output?


Powered by phpBB® Forum Software