Only the most useful options are listed here; see below for the remainder.
All GCC and GNU Fortran options are accepted both by gfortran and by gcc (as well as any other drivers built at the same time, such as g++), since adding GNU Fortran to the GCC distribution enables acceptance of GNU Fortran options by all of the relevant drivers.
In some cases, options have positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual documents only one of these two forms, whichever one is not the default.
Popular values for n include 72 (the standard and the default), 80 (card image), and 132 (corresponding to ``extended-source'' options in some popular compilers). n may also be none, meaning that the entire line is meaningful and that continued character constants never have implicit spaces appended to them to fill out the line. -ffixed-line-length-0 means the same thing as -ffixed-line-length-none.
To disable preprocessing of files with any of the above listed extensions, use the negative form: -nocpp.
The preprocessor is run in traditional mode, be aware that any restrictions of the file-format, e.g. fixed-form line width, apply for preprocessed output as well.
touch foo.f90; gfortran -cpp -dM foo.f90
will show all the predefined macros.
You should be prepared for side effects when using -C; it causes the preprocessor to treat comments as tokens in their own right. For example, comments appearing at the start of what would be a directive line have the effect of turning that line into an ordinary source line, since the first token on the line is no longer a '#'.
Warning: this currently handles C-Style comments only. The preprocessor does not yet recognize Fortran-style comments.
In addition to the side-effects of the -C option, the -CC option causes all C++-style comments inside a macro to be converted to C-style comments. This is to prevent later use of that macro from inadvertently commenting out the remainder of the source line. The -CC option is generally used to support lint comments.
Warning: this currently handles C- and C++-Style comments only. The preprocessor does not yet recognize Fortran-style comments.
If you are invoking the preprocessor from a shell or shell-like program you may need to use the shell's quoting syntax to protect characters such as spaces that have a meaning in the shell syntax.
If you wish to define a function-like macro on the command line, write its argument list with surrounding parentheses before the equals sign (if any). Parentheses are meaningful to most shells, so you will need to quote the option. With sh and csh, "-D'name(args...)=definition'" works.
-D and -U options are processed in the order they are given on the command line. All -imacros file and -include file options are processed after all -D and -U options.
Warnings are diagnostic messages that report constructions which are not inherently erroneous but which are risky or suggest there is likely to be a bug in the program. Unless -Werror is specified, they do not prevent compilation of the program.
You can request many specific warnings with options beginning -W, for example -Wimplicit to request warnings on implicit declarations. Each of these specific warning options also has a negative form beginning -Wno- to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
These options control the amount and kinds of errors and warnings produced by GNU Fortran:
Valid Fortran 95 programs should compile properly with or without this option. However, without this option, certain GNU extensions and traditional Fortran features are supported as well. With this option, many of them are rejected.
Some users try to use -pedantic to check programs for conformance. They soon find that it does not do quite what they want---it finds some nonstandard practices, but not all. However, improvements to GNU Fortran in this area are welcome.
This should be used in conjunction with -std=f95, -std=f2003 or -std=f2008.
The following example will trigger the warning.
interface
subroutine bar(a,b)
integer, intent(in) :: a
integer, intent(out) :: b
end subroutine
end interface
integer :: a
call bar(a,a)
This currently produces a warning under the following circumstances:
Some of these have no effect when compiling programs written in Fortran.
Some of the routines in the Fortran runtime library, like CPU_TIME, are likely to trigger floating point exceptions when "ffpe-trap=precision" is used. For this reason, the use of "ffpe-trap=precision" is not recommended.
It also affects the search paths used by cpp when used to preprocess Fortran source.
Also note that the general behavior of -I and "INCLUDE" is pretty much the same as of -I with "#include" in the cpp preprocessor, with regard to looking for header.gcc files and other such things.
This path is also used to search for .mod files when previously compiled modules are required by a "USE" statement.
The default is the current directory.
-M is deprecated to avoid conflicts with existing GCC options.
This option has an effect only when used in the main program. The "CONVERT" specifier and the GFORTRAN_CONVERT_UNIT environment variable override the default specified by -fconvert.
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.
The calling conventions used by g77 (originally implemented in f2c) require functions that return type default "REAL" 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 default GNU calling conventions, such functions simply return their results as they would in GNU C---default "REAL" functions return the C type "float", and "COMPLEX" functions return the GNU C type "complex". Additionally, this option implies the -fsecond-underscore option, unless -fno-second-underscore is explicitly requested.
This does not affect the generation of code that interfaces with the libgfortran library.
Caution: It is not a good idea to mix Fortran code compiled with -ff2c with code compiled with the default -fno-f2c calling conventions as, calling "COMPLEX" or default "REAL" functions between program parts which were compiled with different calling conventions will break at execution time.
Caution: This will break code which passes intrinsic functions of type default "REAL" or "COMPLEX" as actual arguments, as the library implementations use the -fno-f2c calling conventions.
With -funderscoring in effect, GNU Fortran appends one underscore to external names with no underscores. This is done to ensure compatibility with code produced by many UNIX Fortran compilers.
Caution: The default behavior of GNU Fortran is incompatible with f2c and g77, please use the -ff2c option if you want object files compiled with GNU Fortran to be compatible with object code created with these tools.
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 GNU Fortran code with other languages.
Note that just because the names match does not mean that the interface implemented by GNU Fortran for an external name matches the interface implemented by some other language for that same name. That is, getting code produced by GNU Fortran 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 GNU Fortran 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.
This option has no effect if -fno-underscoring is in effect. It is implied by the -ff2c option.
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_". This is required for compatibility with g77 and f2c, and is implied by use of the -ff2c option.
Some checks require that -fbounds-check is set for the compilation of the main program.
Note: In the future this may also include other forms of checking, e.g., checking substring references.
Note: The warning is only printed once per location.
C<program test>
C<implicit none>
C<integer j>
C<integer, parameter :: n = 100000>
C<integer, parameter :: i(n) = (/ (2*j, j = 1, n) /)>
C<print '(10(I0,1X))', i>
C<end program test>
Caution: This option can lead to long compile times and excessively large object files.
The default value for n is 65535.
This option currently only affects local arrays declared with constant bounds, and may not apply to all character variables. Future versions of GNU Fortran may improve this behavior.
The default value for n is 32768.
This should result in faster accesses to the array. However it can introduce significant overhead to the function call, especially when the passed data is noncontiguous.
The default value for n is 30.
Note that the -finit-real=nan option initializes "REAL" and "COMPLEX" variables with a quiet NaN.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being ``Funding Free Software'', the Front-Cover Texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the gfdl(7) man page.
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.