22.5 GLOBALS

     Global name name defined at ... already defined...
     Global name name at ... has different type...
     Too many arguments passed to name at ...
     Too few arguments passed to name at ...
     Argument #n of name is ...

These messages all identify disagreements about the global procedure named name among different program units (usually including name itself).

Whether a particular disagreement is reported as a warning or an error can depend on the relative order of the disagreeing portions of the source file.

Disagreements between a procedure invocation and the subsequent procedure itself are, usually, diagnosed as errors when the procedure itself precedes the invocation. Other disagreements are diagnosed via warnings.

This distinction, between warnings and errors, is due primarily to the present tendency of the gcc back end to inline only those procedure invocations that are preceded by the corresponding procedure definitions. If the gcc back end is changed to inline “forward references”, in which invocations precede definitions, the g77 front end will be changed to treat both orderings as errors, accordingly.

The sorts of disagreements that are diagnosed by g77 include whether a procedure is a subroutine or function; if it is a function, the type of the return value of the procedure; the number of arguments the procedure accepts; and the type of each argument.

Disagreements regarding global names among program units in a Fortran program should be fixed in the code itself. However, if that is not immediately practical, and the code has been working for some time, it is possible it will work when compiled with the -fno-globals option.

The -fno-globals option causes these diagnostics to all be warnings and disables all inlining of references to global procedures (to avoid subsequent compiler crashes and bad-code generation). Use of the -Wno-globals option as well as -fno-globals suppresses all of these diagnostics. (-Wno-globals by itself disables only the warnings, not the errors.)

After using -fno-globals to work around these problems, it is wise to stop using that option and address them by fixing the Fortran code, because such problems, while they might not actually result in bugs on some systems, indicate that the code is not as portable as it could be. In particular, the code might appear to work on a particular system, but have bugs that affect the reliability of the data without exhibiting any other outward manifestations of the bugs.