Node: Code Gen Options, Next: , Previous: Directory Options, Up: Invoking G77

Options for Code Generation Conventions

These machine-independent options control the interface conventions used in code generation.

Most of them have both positive and negative forms; the negative form of -ffoo would be -fno-foo. In the table below, only one of the forms is listed--the one which is not the default. You can figure out the other form by either removing no- or adding it.

Treat each program unit as if the SAVE statement was specified for every local variable and array referenced in it. Does not affect common blocks. (Some Fortran compilers provide this option under the name -static.)
Specify that variables and arrays that are local to a program unit (not in a common block and not passed as an argument) are to be initialized to binary zeros.

Since there is a run-time penalty for initialization of variables that are not given the SAVE attribute, it might be a good idea to also use -fno-automatic with -finit-local-zero.

Do not generate code designed to be compatible with code generated by f2c use the GNU calling conventions instead.

The f2c calling conventions require functions that return type REAL(KIND=1) to actually return the C type double, and functions that return type COMPLEX to return the values via an extra argument in the calling sequence that points to where to store the return value. Under the GNU calling conventions, such functions simply return their results as they would in GNU C--REAL(KIND=1) functions return the C type float, and COMPLEX functions return the GNU C type complex (or its struct equivalent).

This does not affect the generation of code that interfaces with the libg2c library.

However, because the libg2c library uses f2c calling conventions, g77 rejects attempts to pass intrinsics implemented by routines in this library as actual arguments when -fno-f2c is used, to avoid bugs when they are actually called by code expecting the GNU calling conventions to work.

For example, INTRINSIC ABS;CALL FOO(ABS) is rejected when -fno-f2c is in force. (Future versions of the g77 run-time library might offer routines that provide GNU-callable versions of the routines that implement the f2c intrinsics that may be passed as actual arguments, so that valid programs need not be rejected when -fno-f2c is used.)

Caution: If -fno-f2c is used when compiling any source file used in a program, it must be used when compiling all Fortran source files used in that program.

Specify that use of libg2c (or the original libf2c) is required. This is the default for the current version of g77

Currently it is not valid to specify -fno-f2c-library. This option is provided so users can specify it in shell scripts that build programs and libraries that require the libf2c library, even when being compiled by future versions of g77 that might otherwise default to generating code for an incompatible library.

Do not transform names of entities specified in the Fortran source file by appending underscores to them.

With -funderscoring in effect, g77 appends two underscores to names with underscores and one underscore to external names with no underscores. (g77 also appends two underscores to internal names with underscores to avoid naming collisions with external names. The -fno-second-underscore option disables appending of the second underscore in all cases.)

This is done to ensure compatibility with code produced by many UNIX Fortran compilers, including f2c which perform the same transformations.

Use of -fno-underscoring is not recommended unless you are experimenting with issues such as integration of (GNU) Fortran into existing system environments (vis-a-vis existing libraries, tools, and so on).

For example, with -funderscoring, and assuming other defaults like -fcase-lower and that j() and max_count() are external functions while my_var and lvar are local variables, a statement like

          I = J() + MAX_COUNT (MY_VAR, LVAR)

is implemented as something akin to:

          i = j_() + max_count__(&my_var__, &lvar);

With -fno-underscoring, the same statement is implemented as:

          i = j() + max_count(&my_var, &lvar);

Use of -fno-underscoring allows direct specification of user-defined names while debugging and when interfacing g77 code with other languages.

Note that just because the names match does not mean that the interface implemented by g77 for an external name matches the interface implemented by some other language for that same name. That is, getting code produced by g77 to link to code produced by some other compiler using this or any other method can be only a small part of the overall solution--getting the code generated by both compilers to agree on issues other than naming can require significant effort, and, unlike naming disagreements, linkers normally cannot detect disagreements in these other areas.

Also, note that with -fno-underscoring, the lack of appended underscores introduces the very real possibility that a user-defined external name will conflict with a name in a system library, which could make finding unresolved-reference bugs quite difficult in some cases--they might occur at program run time, and show up only as buggy behavior at run time.

In future versions of g77 we hope to improve naming and linking issues so that debugging always involves using the names as they appear in the source, even if the names as seen by the linker are mangled to prevent accidental linking between procedures with incompatible interfaces.

Do not append a second underscore to names of entities specified in the Fortran source file.

This option has no effect if -fno-underscoring is in effect.

Otherwise, with this option, an external name such as MAX_COUNT is implemented as a reference to the link-time external symbol max_count_, instead of max_count__.

Ignore the #ident directive.
Treat initial values of zero as if they were any other value.

As of version 0.5.18, g77 normally treats DATA and other statements that are used to specify initial values of zero for variables and arrays as if no values were actually specified, in the sense that no diagnostics regarding multiple initializations are produced.

This is done to speed up compiling of programs that initialize large arrays to zeros.

Use -fzeros to revert to the simpler, slower behavior that can catch multiple initializations by keeping track of all initializations, zero or otherwise.

Caution: Future versions of g77 might disregard this option (and its negative form, the default) or interpret it somewhat differently. The interpretation changes will affect only non-standard programs; standard-conforming programs should not be affected.

Implement COMPLEX arithmetic via emulation, instead of using the facilities of the gcc back end that provide direct support of complex arithmetic.

(gcc had some bugs in its back-end support for complex arithmetic, due primarily to the support not being completed as of version 2.8.1 and egcs 1.1.2.)

Use -femulate-complex if you suspect code-generation bugs, or experience compiler crashes, that might result from g77 using the COMPLEX support in the gcc back end. If using that option fixes the bugs or crashes you are seeing, that indicates a likely g77 bugs (though, all compiler crashes are considered bugs), so, please report it. (Note that the known bugs, now believed fixed, produced compiler crashes rather than causing the generation of incorrect code.)

Use of this option should not affect how Fortran code compiled by g77 works in terms of its interfaces to other code, e.g. that compiled by f2c

As of GCC version 3.0, this option is not necessary anymore.

Caution: Future versions of g77 might ignore both forms of this option.




Version info: These options are not supported by versions of g77 based on gcc version 2.8.

These options specify to what degree aliasing (overlap) is permitted between arguments (passed as pointers) and COMMON (external, or public) storage.

The default for Fortran code, as mandated by the FORTRAN 77 and Fortran 90 standards, is -fargument-noalias-global. The default for code written in the C language family is -fargument-alias.

Note that, on some systems, compiling with -fforce-addr in effect can produce more optimal code when the default aliasing options are in effect (and when optimization is enabled).

See Aliasing Assumed To Work, for detailed information on the implications of compiling Fortran code that depends on the ability to alias dummy arguments.

Disable diagnostics about inter-procedural analysis problems, such as disagreements about the type of a function or a procedure's argument, that might cause a compiler crash when attempting to inline a reference to a procedure within a program unit. (The diagnostics themselves are still produced, but as warnings, unless -Wno-globals is specified, in which case no relevant diagnostics are produced.)

Further, this option disables such inlining, to avoid compiler crashes resulting from incorrect code that would otherwise be diagnosed.

As such, this option might be quite useful when compiling existing, "working" code that happens to have a few bugs that do not generally show themselves, but which g77 diagnoses.

Use of this option therefore has the effect of instructing g77 to behave more like it did up through version, when it paid little or no attention to disagreements between program units about a procedure's type and argument information, and when it performed no inlining of procedures (except statement functions).

Without this option, g77 defaults to performing the potentially inlining procedures as it started doing in version 0.5.20, but as of version 0.5.21, it also diagnoses disagreements that might cause such inlining to crash the compiler as (fatal) errors, and warns about similar disagreements that are currently believed to not likely to result in the compiler later crashing or producing incorrect code.

Use back end's C-like constructs (pointer plus offset) instead of its ARRAY_REF construct to handle all array references.

Note: This option is not supported. It is intended for use only by g77 developers, to evaluate code-generation issues. It might be removed at any time.

Enable generation of run-time checks for array subscripts and substring start and end points against the (locally) declared minimum and maximum values.

The current implementation uses the libf2c library routine s_rnge to print the diagnostic.

However, whereas f2c generates a single check per reference for a multi-dimensional array, of the computed offset against the valid offset range (0 through the size of the array), g77 generates a single check per subscript expression. This catches some cases of potential bugs that f2c does not, such as references to below the beginning of an assumed-size array.

g77 also generates checks for CHARACTER substring references, something f2c currently does not do.

Use the new -ffortran-bounds-check option to specify bounds-checking for only the Fortran code you are compiling, not necessarily for code written in other languages.

Note: To provide more detailed information on the offending subscript, g77 provides the libg2c run-time library routine s_rnge with somewhat differently-formatted information. Here's a sample diagnostic:

          Subscript out of range on file line 4, procedure rnge.f/bf.
          Attempt to access the -6-th element of variable b[subscript-2-of-2].

The above message indicates that the offending source line is line 4 of the file rnge.f, within the program unit (or statement function) named bf. The offended array is named b. The offended array dimension is the second for a two-dimensional array, and the offending, computed subscript expression was -6.

For a CHARACTER substring reference, the second line has this appearance:

          Attempt to access the 11-th element of variable a[start-substring].

This indicates that the offended CHARACTER variable or array is named a, the offended substring position is the starting (leftmost) position, and the offending substring expression is 11.

(Though the verbage of s_rnge is not ideal for the purpose of the g77 compiler, the above information should provide adequate diagnostic abilities to it users.)

See Options for Code Generation Conventions, for information on more options offered by the GBE shared by g77 gcc and other GNU compilers.

Some of these do not work when compiling programs written in Fortran:


You should not use these except strictly the same way as you used them to build the version of libg2c with which you will be linking all code compiled by g77 with the same option.
This probably either has no effect on Fortran programs, or makes them act loopy.
Do not use this when compiling Fortran programs, or there will be Trouble.
This probably will break any calls to the libg2c library, at the very least, even if it is built with the same option.