g77 to generate, in
some cases, faster code, by not needing to allow to the possibility
of linking with code compiled by
For example, this affects how
COMPLEX(KIND=2) functions are called.
-fno-f2c, they are
compiled as returning the appropriate
in many configurations).
-ff2c in force, they
are compiled differently (with perhaps slower run-time performance)
to accommodate the restrictions inherent in
f2c's use of K&R
C as an intermediate language--
double type, while
COMPLEX functions return
void and use an extra argument pointing to a place for the functions to
return their values.
It is possible that, in some cases, leaving
-ff2c in force
might produce faster code than using
Feel free to experiment, but remember to experiment with changing the way
entire programs and their Fortran libraries are compiled at
a time, since this sort of experimentation affects the interface
of code generated for a Fortran source file--that is, it affects
f2c compatibility is a fairly static target to achieve,
though not necessarily perfectly so, since, like
g77, it is
still being improved.
to generate code that will probably be incompatible with code
generated by future versions of
g77 when the same option
is in force.
You should make sure you are always able to recompile complete
programs from source code when upgrading to new versions of
f2c, especially when using options such as
Therefore, if you are using
g77 to compile libraries and other
object files for possible future use and you don't want to require
recompilation for future use with subsequent versions of
you might want to stick with
f2c compatibility for now, and
carefully watch for any announcements about changes to the
libf2c interface that might affect existing programs
(thus requiring recompilation).
It is probable that a future version of
g77 will not,
by default, generate object files compatible with
and that version probably would no longer use
If you expect to depend on this compatibility in the
long term, use the options
-ff2c -ff2c-library when compiling
all of the applicable code.
This should cause future versions of
g77 either to produce
compatible code (at the expense of the availability of some features and
performance), or at the very least, to produce diagnostics.
g77 produces will no longer be named
when it is no longer generally compatible with
It will likely be referred to, and, if installed as a distinct
libg77, or some other as-yet-unused name.)