Node: Dropping f2c Compatibility, Next: , Up: Other Compilers



Dropping f2c Compatibility

Specifying -fno-f2c allows g77 to generate, in some cases, faster code, by not needing to allow to the possibility of linking with code compiled by f2c.

For example, this affects how REAL(KIND=1), COMPLEX(KIND=1), and COMPLEX(KIND=2) functions are called. With -fno-f2c, they are compiled as returning the appropriate gcc type (float, __complex__ float, __complex__ double, in many configurations).

With -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--REAL(KIND=1) functions return C's 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 -fno-f2c. 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 object compatibility.

Note that f2c compatibility is a fairly static target to achieve, though not necessarily perfectly so, since, like g77, it is still being improved. However, specifying -fno-f2c causes g77 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 g77 or f2c, especially when using options such as -fno-f2c.

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 g77, you might want to stick with f2c compatibility for now, and carefully watch for any announcements about changes to the f2c/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 f2c, and that version probably would no longer use libf2c. 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.

(The library g77 produces will no longer be named libg2c when it is no longer generally compatible with libf2c. It will likely be referred to, and, if installed as a distinct library, named libg77, or some other as-yet-unused name.)