``Extra warnings'' are issued for:

1. Unused parameters to a procedure (when -Wunused also is specified).
2. Overflows involving floating-point constants (not available for certain configurations).

See Section Options to Request or Suppress Warnings of

Using and Porting GNU CC

, for information on more options offered by the GBE shared by g77, gcc, and other GNU compilers.

Some of these have no effect when compiling programs written in Fortran:

-Wcomment


-Wformat


-Wparentheses


-Wswitch


-Wtraditional


-Wshadow


-Wid-clash-len


-Wlarger-than-len


-Wconversion


-Waggregate-return


-Wredundant-decls


These options all could have some relevant meaning for GNU Fortran programs, but are not yet supported.

Options for Debugging Your Program or GNU Fortran

GNU Fortran has various special options that are used for debugging either your program or g77.

-g


Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.

Support for this option in Fortran programs is incomplete. In particular, names of variables and arrays in common blocks or that are storage-associated via EQUIVALENCE are unavailable to the debugger.

However, version 0.5.19 of g77 does provide this information in a rudimentary way, as controlled by the -fdebug-kludge option.

See Options for Code Generation Conventions, for more information.

See Section Options for Debugging Your Program or GNU CC of

Using and Porting GNU CC

, for more information on debugging options.

Options That Control Optimization

Most Fortran users will want to use no optimization when developing and testing programs, and use -O or -O2 when compiling programs for late-cycle testing and for production use.

The following flags have particular applicability when compiling Fortran programs:

-malign-double


(Intel 386 architecture only.)

Noticeably improves performance of g77 programs making heavy use of REAL(KIND=2) (DOUBLE PRECISION) data on some systems. In particular, systems using Pentium, Pentium Pro, 586, and 686 implementations of the i386 architecture execute programs faster when REAL(KIND=2) (DOUBLE PRECISION) data are aligned on 64-bit boundaries in memory.

This option can, at least, make benchmark results more consistent across various system configurations, versions of the program, and data sets.

Note: The warning in the gcc documentation about this option does not apply, generally speaking, to Fortran code compiled by g77.

Also note: g77 fixes a gcc backend bug to allow -malign-double to work generally, not just with statically-allocated data.

Also also note: The negative form of -malign-double is -mno-align-double, not -benign-double.

-ffloat-store


Might help a Fortran program that depends on exact IEEE conformance on some machines, but might slow down a program that doesn't.

-fforce-mem


-fforce-addr


Might improve optimization of loops.

-fno-inline


Don't compile statement functions inline. Might reduce the size of a program unit---which might be at expense of some speed (though it should compile faster). Note that if you are not optimizing, no functions can be expanded inline.

-ffast-math


Might allow some programs designed to not be too dependent on IEEE behavior for floating-point to run faster, or die trying.

-fstrength-reduce


Might make some loops run faster.

-frerun-cse-after-loop


-fexpensive-optimizations


-fdelayed-branch


-fschedule-insns


-fschedule-insns2


-fcaller-saves


Might improve performance on some code.

-funroll-loops


Definitely improves performance on some code.

-funroll-all-loops


Definitely improves performance on some code.

-fno-move-all-movables


-fno-reduce-all-givs


-fno-rerun-loop-opt


Each of these might improve performance on some code.

Analysis of Fortran code optimization and the resulting optimizations triggered by the above options were contributed by Toon Moene (toon@moene.indiv.nluug.nl).

These three options are intended to be removed someday, once they have helped determine the efficacy of various approaches to improving the performance of Fortran code.

Please let us know how use of these options affects the performance of your production code. We're particularly interested in code that runs faster when these options are disabled, and in non-Fortran code that benefits when they are enabled via the above gcc command-line options.

See Section Options That Control Optimization of

Using and Porting GNU CC

, for more information on options to optimize the generated machine code.

Options Controlling the Preprocessor

These options control the C preprocessor, which is run on each C source file before actual compilation.

See Section Options Controlling the Preprocessor of

Using and Porting GNU CC

, for information on C preprocessor options.

Some of these options also affect how g77 processes the INCLUDE directive. Since this directive is processed even when preprocessing is not requested, it is not described in this section. See Options for Directory Search, for information on how g77 processes the INCLUDE directive.

However, the INCLUDE directive does not apply preprocessing to the contents of the included file itself.

Therefore, any file that contains preprocessor directives (such as #include, #define, and #if) must be included via the #include directive, not via the INCLUDE directive. Therefore, any file containing preprocessor directives, if included, is necessarily included by a file that itself contains preprocessor directives.

Options for Directory Search

These options affect how the cpp preprocessor searches for files specified via the #include directive. Therefore, when compiling Fortran programs, they are meaningful when the preproecssor is used.

Some of these options also affect how g77 searches for files specified via the INCLUDE directive, although files included by that directive are not, themselves, preprocessed. These options are:

-I-


-Idir


These affect interpretation of the INCLUDE directive (as well as of the #include directive of the cpp preprocessor).

Note that -Idir must be specified without any spaces between -I and the directory name---that is, -Ifoo/bar is valid, but -I foo/bar is rejected by the g77 compiler (though the preprocessor supports the latter form). 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.

See Section Options for Directory Search of

Using and Porting GNU CC

, for information on the -I option.

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.

-fno-automatic


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.)

-finit-local-zero


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.

-fno-f2c


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 libf2c library.

However, because the libf2c 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-callable 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.

-ff2c-library


Specify that use of 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.

-fno-underscoring


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-compiled 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.

-fno-second-underscore


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__.

-fno-ident


Ignore the #ident directive.

-fzeros


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.

-fdebug-kludge


Emit information on COMMON and EQUIVALENCE members that might help users of debuggers work around lack of proper debugging information on such members.

As of version 0.5.19, g77 offers this option to emit information on members of aggregate areas to help users while debugging. This information consists of establishing the type and contents of each such member so that, when a debugger is asked to print the contents, the printed information provides rudimentary debugging information. This information identifies the name of the aggregate area (either the COMMON block name, or the g77-assigned name for the EQUIVALENCE name) and the offset, in bytes, of the member from the beginning of the area.

Using gdb, this information is not coherently displayed in the Fortran language mode, so temporarily switching to the C language mode to display the information is suggested. Use set language c and set language fortran to accomplish this.

For example:

      COMMON /X/A,B
      EQUIVALENCE (C,D)
      CHARACTER XX*50
      EQUIVALENCE (I,XX(20:20))
      END
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
(gdb) b MAIN__
Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
(gdb) r
Starting program: /home/user/a.out
Breakpoint 1, MAIN__ () at cd.f:5
Current language:  auto; currently fortran
(gdb) set language c
Warning: the current language does not match this frame.
(gdb) p a
$2 = "At (COMMON) `x_' plus 0 bytes"
(gdb) p b
$3 = "At (COMMON) `x_' plus 4 bytes"
(gdb) p c
$4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
(gdb) p d
$5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
(gdb) p i
$6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
(gdb) p xx
$7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
(gdb) set language fortran
(gdb) 

Use -fdebug-kludge to generate this information, which might make some programs noticeably larger.

Caution: Future versions of g77 might disregard this option (and its negative form). Current plans call for this to happen when published versions of g77 and gdb exist that provide proper access to debugging information on COMMON and EQUIVALENCE members.

-fno-emulate-complex


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

gcc has some known problems in its back-end support for complex arithmetic, due primarily to the support not being completed as of version 2.7.2.2. Other front ends for the gcc back end avoid this problem by emulating complex arithmetic at a higher level, so the back end sees arithmetic on the real and imaginary components. To make g77 more portable to systems where complex support in the gcc back end is particularly troublesome, g77 now defaults to performing the same kinds of emulations done by these other front ends.

Use -fno-emulate-complex to try the complex support in the gcc back end, in case it works and produces faster programs. So far, all the known bugs seem to involve compile-time crashes, rather than 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.

Caution: Future versions of g77 are likely to change the default for this option to -fno-emulate-complex, and perhaps someday ignore both forms of this option.

Also, it is possible that use of the -fno-emulate-complex option could result in incorrect code being silently produced by g77. But, this is generally true of compilers anyway, so, as usual, test the programs you compile before assuming they are working.

-falias-check


-fargument-alias


-fargument-noalias


-fno-argument-noalias-global


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.

-fno-globals


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 g77 exposes via a diagnostic.

Use of this option therefore has the effect of instructing g77 to behave more like it did up through version 0.5.19.1, 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.

See Section Options for Code Generation Conventions of

Using and Porting GNU CC

, 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:

-fpcc-struct-return


-freg-struct-return


You should not use these except strictly the same way as you used them to build the version of libf2c with which you will be linking all code compiled by g77 with the same option.

-fshort-double


This probably either has no effect on Fortran programs, or makes them act loopy.

-fno-common


Do not use this when compiling Fortran programs, or there will be Trouble.

-fpack-struct


This probably will break any calls to the libf2c library, at the very least, even if it is built with the same option.

Environment Variables Affecting GNU Fortran

GNU Fortran currently does not make use of any environment variables to control its operation above and beyond those that affect the operation of gcc.

See Section Environment Variables Affecting GNU CC of

Using and Porting GNU CC

, for information on environment variables.

News About GNU Fortran

Changes made to recent versions of GNU Fortran are listed below, with the most recent version first.

The changes are generally listed in order:

1. Code-generation and run-time-library bugs
2. Compiler and run-time-library crashes involving valid code
3. New features
4. Fixes and enhancements to existing features
5. New diagnostics
6. Internal improvements
7. Miscellany

This order is not strict---for example, some items involve a combination of these elements.

In 0.5.22:

• Fix code generation for iterative DO loops that have one or more references to the iteration variable, or to aliases of it, in their control expressions. For example, DO 10 J=2,J now is compiled correctly.
• Fix a code-generation bug that afflicted Intel x86 targets when -O2 was specified compiling, for example, an old version of the DNRM2 routine.

  The x87 coprocessor stack was being mismanaged in cases involving assigned GOTO and ASSIGN.

• Fix DTime intrinsic so as not to truncate results to integer values (on some systems).
• Fix SIGNAL intrinsic so it offers portable support for 64-bit systems (such as Digital Alphas running GNU/Linux).
• Fix run-time crash involving NAMELIST on 64-bit machines such as Alphas.
• Fix g77 version of libf2c so it no longer produces a spurious I/O recursion diagnostic at run time when an I/O operation (such as READ *,I) is interrupted in a manner that causes the program to be terminated via the f_exit routine (such as via C-c).
• Fix g77 crash triggered by CASE statement with an omitted lower or upper bound.
• Fix g77 crash compiling references to CPU_Time intrinsic.
• Fix g77 crash (or apparently infinite run-time) when compiling certain complicated expressions involving COMPLEX arithmetic (especially multiplication).
• Fix g77 crash on statements such as PRINT *, (REAL(Z(I)),I=1,2), where Z is DOUBLE COMPLEX.
• Fix a g++ crash.
• Support FORMAT(I<expr>) when expr is a compile-time constant INTEGER expression.
• Fix g77 -g option so procedures that use ENTRY can be stepped through, line by line, in gdb.
• Fix a profiling-related bug in gcc back end for Intel x86 architecture.
• Allow any REAL argument to intrinsics Second and CPU_Time.
• Allow any numeric argument to intrinsics Int2 and Int8.
• Use tempnam, if available, to open scratch files (as in OPEN(STATUS='SCRATCH') so that the TMPDIR environment variable, if present, is used.
• Rename the gcc keyword restrict to __restrict__, to avoid rejecting valid, existing, C programs. Support for restrict is now more like support for complex.
• Fix -fpedantic to not reject procedure invocations such as I=J() and CALL FOO().
• Fix -fugly-comma to affect invocations of only external procedures. Restore rejection of gratuitous trailing omitted arguments to intrinsics, as in I=MAX(3,4,,).
• Fix compiler so it accepts -fgnu-intrinsics-* and -fbadu77-intrinsics-* options.
• Improve diagnostic messages from libf2c so it is more likely that the printing of the active format string is limited to the string, with no trailing garbage being printed.

  (Unlike f2c, g77 did not append a null byte to its compiled form of every format string specified via a FORMAT statement. However, f2c would exhibit the problem anyway for a statement like PRINT '(I)garbage', 1 by printing (I)garbage as the format string.)

• Improve compilation of FORMAT expressions so that a null byte is appended to the last operand if it is a constant. This provides a cleaner run-time diagnostic as provided by libf2c for statements like PRINT '(I1', 42.
• Fix various crashes involving code with diagnosed errors.
• Fix cross-compilation bug when configuring libf2c.
• Improve diagnostics.
• Improve documentation and indexing.
• Upgrade to libf2c as of 1997-09-23. This fixes a formatted-I/O bug that afflicted 64-bit systems with 32-bit integers (such as Digital Alpha running GNU/Linux).

In 0.5.21:

• Fix a code-generation bug introduced by 0.5.20 caused by loop unrolling (by specifying -funroll-loops or similar). This bug afflicted all code compiled by version 2.7.2.2.f.2 of gcc (C, C++, Fortran, and so on).
• Fix a code-generation bug manifested when combining local EQUIVALENCE with a DATA statement that follows the first executable statement (or is treated as an executable-context statement as a result of using the -fpedantic option).
• Fix a compiler crash that occured when an integer division by a constant zero is detected. Instead, when the -W option is specified, the gcc back end issues a warning about such a case. This bug afflicted all code compiled by version 2.7.2.2.f.2 of gcc (C, C++, Fortran, and so on).
• Fix a compiler crash that occurred in some cases of procedure inlining. (Such cases became more frequent in 0.5.20.)
• Fix a compiler crash resulting from using DATA or similar to initialize a COMPLEX variable or array to zero.
• Fix compiler crashes involving use of AND, OR, or XOR intrinsics.
• Fix compiler bug triggered when using a COMMON or EQUIVALENCE variable as the target of an ASSIGN or assigned-GOTO statement.
• Fix compiler crashes due to using the name of a some non-standard intrinsics (such as FTELL or FPUTC) as such and as the name of a procedure or common block. Such dual use of a name in a program is allowed by the standard.
• Place automatic arrays on the stack, even if SAVE or the -fno-automatic option is in effect. This avoids a compiler crash in some cases.
• The -malign-double option now reliably aligns DOUBLE PRECISION optimally on Pentium and Pentium Pro architectures (586 and 686 in gcc).
• New option -Wno-globals disables warnings about ``suspicious'' use of a name both as a global name and as the implicit name of an intrinsic, and warnings about disagreements over the number or natures of arguments passed to global procedures, or the natures of the procedures themselves.

  The default is to issue such warnings, which are new as of this version of g77.

• New option -fno-globals disables diagnostics about potentially fatal disagreements analysis problems, such as disagreements over the number or natures of arguments passed to global procedures, or the natures of those procedures themselves.

  The default is to issue such diagnostics and flag the compilation as unsuccessful. With this option, the diagnostics are issued as warnings, or, if -Wno-globals is specified, are not issued at all.

  This option also disables inlining of global procedures, to avoid compiler crashes resulting from coding errors that these diagnostics normally would identify.

• Diagnose cases where a reference to a procedure disagrees with the type of that procedure, or where disagreements about the number or nature of arguments exist. This avoids a compiler crash.
• Fix parsing bug whereby g77 rejected a second initialization specification immediately following the first's closing / without an intervening comma in a DATA statement, and the second specification was an implied-DO list.
• Improve performance of the gcc back end so certain complicated expressions involving COMPLEX arithmetic (especially multiplication) don't appear to take forever to compile.
• Fix a couple of profiling-related bugs in gcc back end.
• Integrate GNU Ada's (GNAT's) changes to the back end, which consist almost entirely of bug fixes. These fixes are circa version 3.10p of GNAT.
• Include some other gcc fixes that seem useful in g77's version of gcc. (See gcc/ChangeLog for details---compare it to that file in the vanilla gcc-2.7.2.3.tar.gz distribution.)
• Fix libU77 routines that accept file and other names to strip trailing blanks from them, for consistency with other implementations. Blanks may be forcibly appended to such names by appending a single null character (CHAR(0)) to the significant trailing blanks.
• Fix CHMOD intrinsic to work with file names that have embedded blanks, commas, and so on.
• Fix SIGNAL intrinsic so it accepts an optional third Status argument.
• Fix IDATE() intrinsic subroutine (VXT form) so it accepts arguments in the correct order. Documentation fixed accordingly, and for GMTIME() and LTIME() as well.
• Make many changes to libU77 intrinsics to support existing code more directly.

  Such changes include allowing both subroutine and function forms of many routines, changing MCLOCK() and TIME() to return INTEGER(KIND=1) values, introducing MCLOCK8() and TIME8() to return INTEGER(KIND=2) values, and placing functions that are intended to perform side effects in a new intrinsic group, badu77.

• Improve libU77 so it is more portable.
• Add options -fbadu77-intrinsics-delete, -fbadu77-intrinsics-hide, and so on.
• Fix crashes involving diagnosed or invalid code.
• g77 and gcc now do a somewhat better job detecting and diagnosing arrays that are too large to handle before these cause diagnostics during the assembler or linker phase, a compiler crash, or generation of incorrect code.
• Make some fixes to alias analysis code.
• Add support for restrict keyword in gcc front end.
• Support gcc version 2.7.2.3 (modified by g77 into version 2.7.2.3.f.1), and remove support for prior versions of gcc.
• Incorporate GNAT's patches to the gcc back end into g77's, so GNAT users do not need to apply GNAT's patches to build both GNAT and g77 from the same source tree.
• Modify make rules and related code so that generation of Info documentation doesn't require compilation using gcc. Now, any ANSI C compiler should be adequate to produce the g77 documentation (in particular, the tables of intrinsics) from scratch.
• Add INT2 and INT8 intrinsics.
• Add CPU_TIME intrinsic.
• Add ALARM intrinsic.
• CTIME intrinsic now accepts any INTEGER argument, not just INTEGER(KIND=2).
• Warn when explicit type declaration disagrees with the type of an intrinsic invocation.
• Support *f771 entry in gcc specs file.
• Fix typo in make rule g77-cross, used only for cross-compiling.
• Fix libf2c build procedure to re-archive library if previous attempt to archive was interrupted.
• Change gcc to unroll loops only during the last invocation (of as many as two invocations) of loop optimization.
• Improve handling of -fno-f2c so that code that attempts to pass an intrinsic as an actual argument, such as CALL FOO(ABS), is rejected due to the fact that the run-time-library routine is, effectively, compiled with -ff2c in effect.
• Fix g77 driver to recognize -fsyntax-only as an option that inhibits linking, just like -c or -S, and to recognize and properly handle the -nostdlib, -M, -MM, -nodefaultlibs, and -Xlinker options.
• Upgrade to libf2c as of 1997-08-16.
• Modify libf2c to consistently and clearly diagnose recursive I/O (at run time).
• g77 driver now prints version information (such as produced by g77 -v) to stderr instead of stdout.
• The .r suffix now designates a Ratfor source file, to be preprocessed via the ratfor command, available separately.
• Fix some aspects of how gcc determines what kind of system is being configured and what kinds are supported. For example, GNU Linux/Alpha ELF systems now are directly supported.
• Improve diagnostics.
• Improve documentation and indexing.
• Include all pertinent files for libf2c that come from netlib.bell-labs.com; give any such files that aren't quite accurate in g77's version of libf2c the suffix .netlib.
• Reserve INTEGER(KIND=0) for future use.

In 0.5.20:

• The -fno-typeless-boz option is now the default.

  This option specifies that non-decimal-radix constants using the prefixed-radix form (such as Z'1234') are to be interpreted as INTEGER constants. Specify -ftypeless-boz to cause such constants to be interpreted as typeless.

  (Version 0.5.19 introduced -fno-typeless-boz and its inverse.)

• Options -ff90-intrinsics-enable and -fvxt-intrinsics-enable now are the defaults.

  Some programs might use names that clash with intrinsic names defined (and now enabled) by these options or by the new libU77 intrinsics. Users of such programs might need to compile them differently (using, for example, -ff90-intrinsics-disable) or, better yet, insert appropriate EXTERNAL statements specifying that these names are not intended to be names of intrinsics.

• The ALWAYS_FLUSH macro is no longer defined when building libf2c, which should result in improved I/O performance, especially over NFS.

  Note: If you have code that depends on the behavior of libf2c when built with ALWAYS_FLUSH defined, you will have to modify libf2c accordingly before building it from this and future versions of g77.

• Dave Love's implementation of libU77 has been added to the version of libf2c distributed with and built as part of g77. g77 now knows about the routines in this library as intrinsics.
• New option -fvxt specifies that the source file is written in VXT Fortran, instead of GNU Fortran.
• The -fvxt-not-f90 option has been deleted, along with its inverse, -ff90-not-vxt.

  If you used one of these deleted options, you should re-read the pertinent documentation to determine which options, if any, are appropriate for compiling your code with this version of g77.

• The -fugly option now issues a warning, as it likely will be removed in a future version.

  (Enabling all the -fugly-* options is unlikely to be feasible, or sensible, in the future, so users should learn to specify only those -fugly-* options they really need for a particular source file.)

• The -fugly-assumed option, introduced in version 0.5.19, has been changed to better accommodate old and new code.
• Make a number of fixes to the g77 front end and the gcc back end to better support Alpha (AXP) machines. This includes providing at least one bug-fix to the gcc back end for Alphas.
• Related to supporting Alpha (AXP) machines, the LOC() intrinsic and %LOC() construct now return values of integer type that is the same width (holds the same number of bits) as the pointer type on the machine.

  On most machines, this won't make a difference, whereas on Alphas, the type these constructs return is INTEGER*8 instead of the more common INTEGER*4.

• Emulate COMPLEX arithmetic in the g77 front end, to avoid bugs in complex support in the gcc back end. New option -fno-emulate-complex causes g77 to revert the 0.5.19 behavior.
• Fix bug whereby REAL A(1), for example, caused a compiler crash if -fugly-assumed was in effect and A was a local (automatic) array. That case is no longer affected by the new handling of -fugly-assumed.
• Fix g77 command driver so that g77 -o foo.f no longer deletes foo.f before issuing other diagnostics, and so the -x option is properly handled.
• Enable inlining of subroutines and functions by the gcc back end. This works as it does for gcc itself---program units may be inlined for invocations that follow them in the same program unit, as long as the appropriate compile-time options are specified.
• Dummy arguments are no longer assumed to potentially alias (overlap) other dummy arguments or COMMON areas when any of these are defined (assigned to) by Fortran code.

  This can result in faster and/or smaller programs when compiling with optimization enabled, though on some systems this effect is observed only when -fforce-addr also is specified.

  New options -falias-check, -fargument-alias, -fargument-noalias, and -fno-argument-noalias-global control the way g77 handles potential aliasing.

• The CONJG() and DCONJG() intrinsics now are compiled in-line.
• The bug-fix for 0.5.19.1 has been re-done. The g77 compiler has been changed back to assume libf2c has no aliasing problems in its implementations of the COMPLEX (and DOUBLE COMPLEX) intrinsics. The libf2c has been changed to have no such problems.

  As a result, 0.5.20 is expected to offer improved performance over 0.5.19.1, perhaps as good as 0.5.19 in most or all cases, due to this change alone.

  Note: This change requires version 0.5.20 of libf2c, at least, when linking code produced by any versions of g77 other than 0.5.19.1. Use g77 -v to determine the version numbers of the libF77, libI77, and libU77 components of the libf2c library. (If these version numbers are not printed---in particular, if the linker complains about unresolved references to names like g77__fvers__---that strongly suggests your installation has an obsolete version of libf2c.)

• New option -fugly-assign specifies that the same memory locations are to be used to hold the values assigned by both statements I = 3 and ASSIGN 10 TO I, for example. (Normally, g77 uses a separate memory location to hold assigned statement labels.)
• FORMAT and ENTRY statements now are allowed to precede IMPLICIT NONE statements.
• Produce diagnostic for unsupported SELECT CASE on CHARACTER type, instead of crashing, at compile time.
• Fix crashes involving diagnosed or invalid code.
• Change approach to building libf2c archive (libf2c.a) so that members are added to it only when truly necessary, so the user that installs an already-built g77 doesn't need to have write access to the build tree (whereas the user doing the build might not have access to install new software on the system).
• Support gcc version 2.7.2.2 (modified by g77 into version 2.7.2.2.f.2), and remove support for prior versions of gcc.
• Upgrade to libf2c as of 1997-02-08, and fix up some of the build procedures.
• Improve general build procedures for g77, fixing minor bugs (such as deletion of any file named f771 in the parent directory of gcc/).
• Enable full support of INTEGER*8 available in libf2c and f2c.h so that f2c users may make full use of its features via the g77 version of f2c.h and the INTEGER*8 support routines in the g77 version of libf2c.
• Improve g77 driver and libf2c so that g77 -v yields version information on the library.
• The SNGL and FLOAT intrinsics now are specific intrinsics, instead of synonyms for the generic intrinsic REAL.
• New intrinsics have been added. These are REALPART, IMAGPART, COMPLEX, LONG, and SHORT.
• A new group of intrinsics, gnu, has been added to contain the new REALPART, IMAGPART, and COMPLEX intrinsics. An old group, dcp, has been removed.
• Complain about industry-wide ambiguous references REAL(expr) and AIMAG(expr), where expr is DOUBLE COMPLEX (or any complex type other than COMPLEX), unless -ff90 option specifies Fortran 90 interpretation or new -fugly-complex option, in conjunction with -fnot-f90, specifies f2c interpretation.
• Make improvements to diagnostics.
• Speed up compiler a bit.
• Improvements to documentation and indexing, including a new chapter containing information on one, later more, diagnostics that users are directed to pull up automatically via a message in the diagnostic itself.

  (Hence the menu item M for the node Diagnostics in the top-level menu of the Info documentation.)

In 0.5.19.1:

• Code-generation bugs afflicting operations on complex data have been fixed.

  These bugs occurred when assigning the result of an operation to a complex variable (or array element) that also served as an input to that operation.

  The operations affected by this bug were: CONJG(), DCONJG(), CCOS(), CDCOS(), CLOG(), CDLOG(), CSIN(), CDSIN(), CSQRT(), CDSQRT(), complex division, and raising a DOUBLE COMPLEX operand to an INTEGER power. (The related generic and Z-prefixed intrinsics, such as ZSIN(), also were affected.)

  For example, C = CSQRT(C), Z = Z/C, and Z = Z**I (where C is COMPLEX and Z is DOUBLE COMPLEX) have been fixed.

In 0.5.19:

• Fix FORMAT statement parsing so negative values for specifiers such as P (e.g. FORMAT(-1PF8.1)) are correctly processed as negative.
• Fix SIGNAL intrinsic so it once again accepts a procedure as its second argument.
• A temporary kludge option provides bare-bones information on COMMON and EQUIVALENCE members at debug time.
• New -fonetrip option specifies FORTRAN-66-style one-trip DO loops.
• New -fno-silent option causes names of program units to be printed as they are compiled, in a fashion similar to UNIX f77 and f2c.
• New -fugly-assumed option specifies that arrays dimensioned via DIMENSION X(1), for example, are to be treated as assumed-size.
• New -fno-typeless-boz option specifies that non-decimal-radix constants using the prefixed-radix form (such as Z'1234') are to be interpreted as INTEGER constants.
• New -ff66 option is a ``shorthand'' option that specifies behaviors considered appropriate for FORTRAN 66 programs.
• New -ff77 option is a ``shorthand'' option that specifies behaviors considered appropriate for UNIX f77 programs.
• New -fugly-comma and -fugly-logint options provided to perform some of what -fugly used to do. -fugly and -fno-ugly are now ``shorthand'' options, in that they do nothing more than enable (or disable) other -fugly-* options.
• Fix parsing of assignment statements involving targets that are substrings of elements of CHARACTER arrays having names such as READ, WRITE, GOTO, and REALFUNCTIONFOO.
• Fix crashes involving diagnosed code.
• Fix handling of local EQUIVALENCE areas so certain cases of valid Fortran programs are not misdiagnosed as improperly extending the area backwards.
• Support gcc version 2.7.2.1.
• Upgrade to libf2c as of 1996-09-26, and fix up some of the build procedures.
• Change code generation for list-directed I/O so it allows for new versions of libf2c that might return non-zero status codes for some operations previously assumed to always return zero.

  This change not only affects how IOSTAT= variables are set by list-directed I/O, it also affects whether END= and ERR= labels are reached by these operations.

• Add intrinsic support for new FTELL and FSEEK procedures in libf2c.
• Modify fseek_() in libf2c to be more portable (though, in practice, there might be no systems where this matters) and to catch invalid whence arguments.
• Some useless warnings from the -Wunused option have been eliminated.
• Fix a problem building the f771 executable on AIX systems by linking with the -bbigtoc option.
• Abort configuration if gcc has not been patched using the patch file provided in the gcc/f/gbe/ subdirectory.
• Add options --help and --version to the g77 command, to conform to GNU coding guidelines. Also add printing of g77 version number when the --verbose (-v) option is used.
• Change internally generated name for local EQUIVALENCE areas to one based on the alphabetically sorted first name in the list of names for entities placed at the beginning of the areas.
• Improvements to documentation and indexing.

In 0.5.18:

• Add some rudimentary support for INTEGER*1, INTEGER*2, INTEGER*8, and their LOGICAL equivalents. (This support works on most, maybe all, gcc targets.)

  Thanks to Scott Snyder (snyder@d0sgif.fnal.gov) for providing the patch for this!

  Among the missing elements from the support for these features are full intrinsic support and constants.

• Add some rudimentary support for the BYTE and WORD type-declaration statements. BYTE corresponds to INTEGER*1, while WORD corresponds to INTEGER*2.

  Thanks to Scott Snyder (snyder@d0sgif.fnal.gov) for providing the patch for this!

• The compiler code handling intrinsics has been largely rewritten to accommodate the new types. No new intrinsics or arguments for existing intrinsics have been added, so there is, at this point, no intrinsic to convert to INTEGER*8, for example.
• Support automatic arrays in procedures.
• Reduce space/time requirements for handling large sparsely initialized aggregate arrays. This improvement applies to only a subset of the general problem to be addressed in 0.6.
• Treat initial values of zero as if they weren't specified (in DATA and type-declaration statements). The initial values will be set to zero anyway, but the amount of compile time processing them will be reduced, in some cases significantly (though, again, this is only a subset of the general problem to be addressed in 0.6).

  A new option, -fzeros, is introduced to enable the traditional treatment of zeros as any other value.

• With -ff90 in force, g77 incorrectly interpreted REAL(Z) as returning a REAL result, instead of as a DOUBLE PRECISION result. (Here, Z is DOUBLE COMPLEX.)

  With -fno-f90 in force, the interpretation remains unchanged, since this appears to be how at least some F77 code using the DOUBLE COMPLEX extension expected it to work.

  Essentially, REAL(Z) in F90 is the same as DBLE(Z), while in extended F77, it appears to be the same as REAL(REAL(Z)).

• An expression involving exponentiation, where both operands were type INTEGER and the right-hand operand was negative, was erroneously evaluated.
• Fix bugs involving DATA implied-DO constructs (these involved an errant diagnostic and a crash, both on good code, one involving subsequent statement-function definition).
• Close INCLUDE files after processing them, so compiling source files with lots of INCLUDE statements does not result in being unable to open INCLUDE files after all the available file descriptors are used up.
• Speed up compiling, especially of larger programs, and perhaps slightly reduce memory utilization while compiling (this is not the improvement planned for 0.6 involving large aggregate areas)---these improvements result from simply turning off some low-level code to do self-checking that hasn't been triggered in a long time.
• Introduce three new options that implement optimizations in the gcc back end (GBE). These options are -fmove-all-movables, -freduce-all-givs, and -frerun-loop-opt, which are enabled, by default, for Fortran compilations. These optimizations are intended to help toon Fortran programs.
• Patch the GBE to do a better job optimizing certain kinds of references to array elements.
• Due to patches to the GBE, the version number of gcc also is patched to make it easier to manage installations, especially useful if it turns out a g77 change to the GBE has a bug.

  The g77-modified version number is the gcc version number with the string .f.n appended, where f identifies the version as enhanced for Fortran, and n is 1 for the first Fortran patch for that version of gcc, 2 for the second, and so on.

  So, this introduces version 2.7.2.f.1 of gcc.

• Make several improvements and fixes to diagnostics, including the removal of two that were inappropriate or inadequate.
• Warning about two successive arithmetic operators, produced by -Wsurprising, now produced only when both operators are, indeed, arithmetic (not relational/boolean).
• -Wsurprising now warns about the remaining cases of using non-integral variables for implied-DO loops, instead of these being rejected unless -fpedantic or -fugly specified.
• Allow SAVE of a local variable or array, even after it has been given an initial value via DATA, for example.
• Introduce an Info version of g77 documentation, which supercedes gcc/f/CREDITS, gcc/f/DOC, and gcc/f/PROJECTS. These files will be removed in a future release. The files gcc/f/BUGS, gcc/f/INSTALL, and gcc/f/NEWS now are automatically built from the texinfo source when distributions are made.

  This effort was inspired by a first pass at translating g77-0.5.16/f/DOC that was contributed to Craig by David Ronis (ronis@onsager.chem.mcgill.ca).

• New -fno-second-underscore option to specify that, when -funderscoring is in effect, a second underscore is not to be appended to Fortran names already containing an underscore.
• Change the way iterative DO loops work to follow the F90 standard. In particular, calculation of the iteration count is still done by converting the start, end, and increment parameters to the type of the DO variable, but the result of the calculation is always converted to the default INTEGER type.

  (This should have no effect on existing code compiled by g77, but code written to assume that use of a wider type for the DO variable will result in an iteration count being fully calculated using that wider type (wider than default INTEGER) must be rewritten.)

• Support gcc version 2.7.2.
• Upgrade to libf2c as of 1996-03-23, and fix up some of the build procedures.

  Note that the email addresses related to f2c have changed---the distribution site now is named netlib.bell-labs.com, and the maintainer's new address is dmg@bell-labs.com.

In 0.5.17:

• Fix serious bug in g77 -v command that can cause removal of a system's /dev/null special file if run by user root.

  All users of version 0.5.16 should ensure that they have not removed /dev/null or replaced it with an ordinary file (e.g. by comparing the output of ls -l /dev/null with ls -l /dev/zero. If the output isn't basically the same, contact your system administrator about restoring /dev/null to its proper status).

  This bug is particularly insidious because removing /dev/null as a special file can go undetected for quite a while, aside from various applications and programs exhibiting sudden, strange behaviors.

  I sincerely apologize for not realizing the implications of the fact that when g77 -v runs the ld command with -o /dev/null that ld tries to remove the executable it is supposed to build (especially if it reports unresolved references, which it should in this case)!

• Fix crash on CHARACTER*(*) FOO in a main or block data program unit.
• Fix crash that can occur when diagnostics given outside of any program unit (such as when input file contains @foo).
• Fix crashes, infinite loops (hangs), and such involving diagnosed code.
• Fix ASSIGN'ed variables so they can be SAVE'd or dummy arguments, and issue clearer error message in cases where target of ASSIGN or ASSIGNed GOTO/FORMAT is too small (which should never happen).
• Make libf2c build procedures work on more systems again by eliminating unnecessary invocations of ld -r -x and mv.
• Fix omission of -funix-intrinsics-··· options in list of permitted options to compiler.
• Fix failure to always diagnose missing type declaration for IMPLICIT NONE.
• Fix compile-time performance problem (which could sometimes crash the compiler, cause a hang, or whatever, due to a bug in the back end) involving exponentiation with a large INTEGER constant for the right-hand operator (e.g. I**32767).
• Fix build procedures so cross-compiling g77 (the fini utility in particular) is properly built using the host compiler.
• Add new -Wsurprising option to warn about constructs that are interpreted by the Fortran standard (and g77) in ways that are surprising to many programmers.
• Add ERF() and ERFC() as generic intrinsics mapping to existing ERF/DERF and ERFC/DERFC specific intrinsics.

  Note: You should specify INTRINSIC ERF,ERFC in any code where you might use these as generic intrinsics, to improve likelihood of diagnostics (instead of subtle run-time bugs) when using a compiler that doesn't support these as intrinsics (e.g. f2c).

• Remove from -fno-pedantic the diagnostic about DO with non-INTEGER index variable; issue that under -Wsurprising instead.
• Clarify some diagnostics that say things like ``ignored'' when that's misleading.
• Clarify diagnostic on use of .EQ./.NE. on LOGICAL operands.
• Minor improvements to code generation for various operations on LOGICAL operands.
• Minor improvement to code generation for some DO loops on some machines.
• Support gcc version 2.7.1.
• Upgrade to libf2c as of 1995-11-15.

In 0.5.16:

• Fix a code-generation bug involving complicated EQUIVALENCE statements not involving COMMON.
• Fix code-generation bugs involving invoking ``gratis'' library procedures in libf2c from code compiled with -fno-f2c by making these procedures known to g77 as intrinsics (not affected by -fno-f2c). This is known to fix code invoking ERF(), ERFC(), DERF(), and DERFC().
• Update libf2c to include netlib patches through 1995-08-16, and #define WANT_LEAD_0 to 1 to make g77-compiled code more consistent with other Fortran implementations by outputting leading zeros in formatted and list-directed output.
• Fix a code-generation bug involving adjustable dummy arrays with high bounds whose primaries are changed during procedure execution, and which might well improve code-generation performance for such arrays compared to f2c plus gcc (but apparently only when using gcc-2.7.0 or later).
• Fix a code-generation bug involving invocation of COMPLEX and DOUBLE COMPLEX FUNCTIONs and doing COMPLEX and DOUBLE COMPLEX divides, when the result of the invocation or divide is assigned directly to a variable that overlaps one or more of the arguments to the invocation or divide.
• Fix crash by not generating new optimal code for X**I if I is nonconstant and the expression is used to dimension a dummy array, since the gcc back end does not support the necessary mechanics (and the gcc front end rejects the equivalent construct, as it turns out).
• Fix crash on expressions like COMPLEX**INTEGER.
• Fix crash on expressions like (1D0,2D0)**2, i.e. raising a DOUBLE COMPLEX constant to an INTEGER constant power.
• Fix crashes and such involving diagnosed code.
• Diagnose, instead of crashing on, statement function definitions having duplicate dummy argument names.
• Fix bug causing rejection of good code involving statement function definitions.
• Fix bug resulting in debugger not knowing size of local equivalence area when any member of area has initial value (via DATA, for example).
• Fix installation bug that prevented installation of g77 driver. Provide for easy selection of whether to install copy of g77 as f77 to replace the broken code.
• Fix gcc driver (affects g77 thereby) to not gratuitously invoke the f771 program (e.g. when -E is specified).
• Fix diagnostic to point to correct source line when it immediately follows an INCLUDE statement.
• Support more compiler options in gcc/g77 when compiling Fortran files. These options include -p, -pg, -aux-info, -P, correct setting of version-number macros for preprocessing, full recognition of -O0, and automatic insertion of configuration-specific linker specs.
• Add new intrinsics that interface to existing routines in libf2c: ABORT, DERF, DERFC, ERF, ERFC, EXIT, FLUSH, GETARG, GETENV, IARGC, SIGNAL, and SYSTEM. Note that ABORT, EXIT, FLUSH, SIGNAL, and SYSTEM are intrinsic subroutines, not functions (since they have side effects), so to get the return values from SIGNAL and SYSTEM, append a final argument specifying an INTEGER variable or array element (e.g. CALL SYSTEM('rm foo',ISTAT)).
• Add new intrinsic group named unix to contain the new intrinsics, and by default enable this new group.
• Move LOC() intrinsic out of the vxt group to the new unix group.
• Improve g77 so that g77 -v by itself (or with certain other options, including -B, -b, -i, -nostdlib, and -V) reports lots more useful version info, and so that long-form options gcc accepts are understood by g77 as well (even in truncated, unambiguous forms).
• Add new g77 option --driver=name to specify driver when default, gcc, isn't appropriate.
• Add support for # directives (as output by the preprocessor) in the compiler, and enable generation of those directives by the preprocessor (when compiling .F files) so diagnostics and debugging info are more useful to users of the preprocessor.
• Produce better diagnostics, more like gcc, with info such as In function `foo': and In file included from...:.
• Support gcc's -fident and -fno-ident options.
• When -Wunused in effect, don't warn about local variables used as statement-function dummy arguments or DATA implied-DO iteration variables, even though, strictly speaking, these are not uses of the variables themselves.
• When -W -Wunused in effect, don't warn about unused dummy arguments at all, since there's no way to turn this off for individual cases (g77 might someday start warning about these)---applies to gcc versions 2.7.0 and later, since earlier versions didn't warn about unused dummy arguments.
• New option -fno-underscoring that inhibits transformation of names (by appending one or two underscores) so users may experiment with implications of such an environment.
• Minor improvement to gcc/f/info module to make it easier to build g77 using the native (non-gcc) compiler on certain machines (but definitely not all machines nor all non-gcc compilers). Please do not report bugs showing problems compilers have with macros defined in gcc/f/target.h and used in places like gcc/f/expr.c.
• Add warning to be printed for each invocation of the compiler if the target machine INTEGER, REAL, or LOGICAL size is not 32 bits, since g77 is known to not work well for such cases (to be fixed in Version 0.6---see Actual Bugs We Haven't Fixed Yet).
• Lots of new documentation (though work is still needed to put it into canonical GNU format).
• Build libf2c with -g0, not -g2, in effect (by default), to produce smaller library without lots of debugging clutter.

In 0.5.15:

• Fix bad code generation involving X**I and temporary, internal variables generated by g77 and the back end (such as for DO loops).
• Fix crash given CHARACTER A;DATA A/.TRUE./.
• Replace crash with diagnostic given CHARACTER A;DATA A/1.0/.
• Fix crash or other erratic behavior when null character constant ('') is encountered.
• Fix crash or other erratic behavior involving diagnosed code.
• Fix code generation for external functions returning type REAL when the -ff2c option is in force (which it is by default) so that f2c compatibility is indeed provided.
• Disallow COMMON I(10) if I has previously been specified with an array declarator.
• New -ffixed-line-length-n option, where n is the maximum length of a typical fixed-form line, defaulting to 72 columns, such that characters beyond column n are ignored, or n is none, meaning no characters are ignored. does not affect lines with & in column 1, which are always processed as if -ffixed-line-length-none was in effect.
• No longer generate better code for some kinds of array references, as gcc back end is to be fixed to do this even better, and it turned out to slow down some code in some cases after all.
• In COMMON and EQUIVALENCE areas with any members given initial values (e.g. via DATA), uninitialized members now always initialized to binary zeros (though this is not required by the standard, and might not be done in future versions of g77). Previously, in some COMMON/EQUIVALENCE areas (essentially those with members of more than one type), the uninitialized members were initialized to spaces, to cater to CHARACTER types, but it seems no existing code expects that, while much existing code expects binary zeros.

In 0.5.14:

• Don't emit bad code when low bound of adjustable array is nonconstant and thus might vary as an expression at run time.
• Emit correct code for calculation of number of trips in DO loops for cases where the loop should not execute at all. (This bug affected cases where the difference between the begin and end values was less than the step count, though probably not for floating-point cases.)
• Fix crash when extra parentheses surround item in DATA implied-DO list.
• Fix crash over minor internal inconsistencies in handling diagnostics, just substitute dummy strings where necessary.
• Fix crash on some systems when compiling call to MVBITS() intrinsic.
• Fix crash on array assignment TYPEddd(···)=···, where ddd is a string of one or more digits.
• Fix crash on DCMPLX() with a single INTEGER argument.
• Fix various crashes involving code with diagnosed errors.
• Support -I option for INCLUDE statement, plus gcc's header.gcc facility for handling systems like MS-DOS.
• Allow INCLUDE statement to be continued across multiple lines, even allow it to coexist with other statements on the same line.
• Incorporate Bellcore fixes to libf2c through 1995-03-15---this fixes a bug involving infinite loops reading EOF with empty list-directed I/O list.
• Remove all the g77-specific auto-configuration scripts, code, and so on, except for temporary substitutes for bsearch() and strtoul(), as too many configure/build problems were reported in these areas. People will have to fix their systems' problems themselves, or at least somewhere other than g77, which expects a working ANSI C environment (and, for now, a GNU C compiler to compile g77 itself).
• Complain if initialized common redeclared as larger in subsequent program unit.
• Warn if blank common initialized, since its size can vary and hence related warnings that might be helpful won't be seen.
• New -fbackslash option, on by default, that causes \ within CHARACTER and Hollerith constants to be interpreted a la GNU C. Note that this behavior is somewhat different from f2c's, which supports only a limited subset of backslash (escape) sequences.
• Make -fugly-args the default.
• New -fugly-init option, on by default, that allows typeless/Hollerith to be specified as initial values for variables or named constants (PARAMETER), and also allows character<->numeric conversion in those contexts---turn off via -fno-ugly-init.
• New -finit-local-zero option to initialize local variables to binary zeros. This does not affect whether they are SAVEd, i.e. made automatic or static.
• New -Wimplicit option to warn about implicitly typed variables, arrays, and functions. (Basically causes all program units to default to IMPLICIT NONE.)
• -Wall now implies -Wuninitialized as with gcc (i.e. unless -O not specified, since -Wuninitialized requires -O), and implies -Wunused as well.
• -Wunused no longer gives spurious messages for unused EXTERNAL names (since they are assumed to refer to block data program units, to make use of libraries more reliable).
• Support %LOC() and LOC() of character arguments.
• Support null (zero-length) character constants and expressions.
• Support f2c's IMAG() generic intrinsic.
• Support ICHAR(), IACHAR(), and LEN() of character expressions that are valid in assignments but not normally as actual arguments.
• Support f2c-style & in column 1 to mean continuation line.
• Allow NAMELIST, EXTERNAL, INTRINSIC, and VOLATILE in BLOCK DATA, even though these are not allowed by the standard.
• Allow RETURN in main program unit.
• Changes to Hollerith-constant support to obey Appendix C of the standard:
  • Now padded on the right with zeros, not spaces.
  • Hollerith ``format specifications'' in the form of arrays of non-character allowed.
  • Warnings issued when non-space truncation occurs when converting to another type.
  • When specified as actual argument, now passed by reference to INTEGER (padded on right with spaces if constant too small, otherwise fully intact if constant wider the INTEGER type) instead of by value.

  Warning: f2c differs on the interpretation of CALL FOO(1HX), which it treats exactly the same as CALL FOO('X'), but which the standard and g77 treat as CALL FOO(%REF('X ')) (padded with as many spaces as necessary to widen to INTEGER), essentially.

• Changes and fixes to typeless-constant support:
  • Now treated as a typeless double-length INTEGER value.
  • Warnings issued when overflow occurs.
  • Padded on the left with zeros when converting to a larger type.
  • Should be properly aligned and ordered on the target machine for whatever type it is turned into.
  • When specified as actual argument, now passed as reference to a default INTEGER constant.
• %DESCR() of a non-CHARACTER expression now passes a pointer to the expression plus a length for the expression just as if it were a CHARACTER expression. For example, CALL FOO(%DESCR(D)), where D is REAL*8, is the same as CALL FOO(D,%VAL(8))).
• Name of multi-entrypoint master function changed to incorporate the name of the primary entry point instead of a decimal value, so the name of the master function for SUBROUTINE X with alternate entry points is now __g77_masterfun_x.
• Remove redundant message about zero-step-count DO loops.
• Clean up diagnostic messages, shortening many of them.
• Fix typo in g77 man page.
• Clarify implications of constant-handling bugs in f/BUGS.
• Generate better code for ** operator with a right-hand operand of type INTEGER.
• Generate better code for SQRT() and DSQRT(), also when -ffast-math specified, enable better code generation for SIN() and COS().
• Generate better code for some kinds of array references.
• Speed up lexing somewhat (this makes the compilation phase noticeably faster).

User-visible Changes

This section describes changes to g77 that are visible to the programmers who actually write and maintain Fortran code they compile with g77. Information on changes to installation procedures, changes to the documentation, and bug fixes is not provided here, unless it is likely to affect how users use g77. See News About GNU Fortran, for information on such changes to g77.

To find out about existing bugs and ongoing plans for GNU Fortran, retrieve {ftp://alpha.gnu.org/g77.plan} or, if you cannot do that, email fortran@gnu.org asking for a recent copy of the GNU Fortran .plan file.

In 0.5.21:

• When the -W option is specified, gcc, g77, and other GNU compilers that incorporate the gcc back end as modified by g77, issue a warning about integer division by constant zero.
• New option -Wno-globals disables warnings about ``suspicious'' use of a name both as a global name and as the implicit name of an intrinsic, and warnings about disagreements over the number or natures of arguments passed to global procedures, or the natures of the procedures themselves.

  The default is to issue such warnings, which are new as of this version of g77.

• New option -fno-globals disables diagnostics about potentially fatal disagreements analysis problems, such as disagreements over the number or natures of arguments passed to global procedures, or the natures of those procedures themselves.

  The default is to issue such diagnostics and flag the compilation as unsuccessful. With this option, the diagnostics are issued as warnings, or, if -Wno-globals is specified, are not issued at all.

  This option also disables inlining of global procedures, to avoid compiler crashes resulting from coding errors that these diagnostics normally would identify.

• Fix libU77 routines that accept file names to strip trailing spaces from them, for consistency with other implementations.
• Fix SIGNAL intrinsic so it accepts an optional third Status argument.
• Make many changes to libU77 intrinsics to support existing code more directly.

  Such changes include allowing both subroutine and function forms of many routines, changing MCLOCK() and TIME() to return INTEGER(KIND=1) values, introducing MCLOCK8() and TIME8() to return INTEGER(KIND=2) values, and placing functions that are intended to perform side effects in a new intrinsic group, badu77.

• Add options -fbadu77-intrinsics-delete, -fbadu77-intrinsics-hide, and so on.
• Add INT2 and INT8 intrinsics.
• Add CPU_TIME intrinsic.
• CTIME intrinsic now accepts any INTEGER argument, not just INTEGER(KIND=2).

In 0.5.20:

• The -fno-typeless-boz option is now the default.

  This option specifies that non-decimal-radix constants using the prefixed-radix form (such as Z'1234') are to be interpreted as INTEGER(KIND=1) constants. Specify -ftypeless-boz to cause such constants to be interpreted as typeless.

  (Version 0.5.19 introduced -fno-typeless-boz and its inverse.)

  See Options Controlling Fortran Dialect, for information on the -ftypeless-boz option.

• Options -ff90-intrinsics-enable and -fvxt-intrinsics-enable now are the defaults.

  Some programs might use names that clash with intrinsic names defined (and now enabled) by these options or by the new libU77 intrinsics. Users of such programs might need to compile them differently (using, for example, -ff90-intrinsics-disable) or, better yet, insert appropriate EXTERNAL statements specifying that these names are not intended to be names of intrinsics.

• The ALWAYS_FLUSH macro is no longer defined when building libf2c, which should result in improved I/O performance, especially over NFS.

  Note: If you have code that depends on the behavior of libf2c when built with ALWAYS_FLUSH defined, you will have to modify libf2c accordingly before building it from this and future versions of g77.

  See Output Assumed To Flush, for more information.

• Dave Love's implementation of libU77 has been added to the version of libf2c distributed with and built by g77. g77 now knows about the routines in this library as intrinsics.
• New option -fvxt specifies that the source file is written in VXT Fortran, instead of GNU Fortran.

  See VXT Fortran, for more information on the constructs recognized when the -fvxt option is specified.

• The -fvxt-not-f90 option has been deleted, along with its inverse, -ff90-not-vxt.

  If you used one of these deleted options, you should re-read the pertinent documentation to determine which options, if any, are appropriate for compiling your code with this version of g77.

  See Other Dialects, for more information.

• The -fugly option now issues a warning, as it likely will be removed in a future version.

  (Enabling all the -fugly-* options is unlikely to be feasible, or sensible, in the future, so users should learn to specify only those -fugly-* options they really need for a particular source file.)

• The -fugly-assumed option, introduced in version 0.5.19, has been changed to better accommodate old and new code. See Ugly Assumed-Size Arrays, for more information.
• Related to supporting Alpha (AXP) machines, the LOC() intrinsic and %LOC() construct now return values of INTEGER(KIND=0) type, as defined by the GNU Fortran language.

  This type is wide enough (holds the same number of bits) as the character-pointer type on the machine.

  On most systems, this won't make a noticable difference, whereas on Alphas and other systems with 64-bit pointers, the INTEGER(KIND=0) type is equivalent to INTEGER(KIND=2) (often referred to as INTEGER*8) instead of the more common INTEGER(KIND=1) (often referred to as INTEGER*4).

• Emulate COMPLEX arithmetic in the g77 front end, to avoid bugs in complex support in the gcc back end. New option -fno-emulate-complex causes g77 to revert the 0.5.19 behavior.
• Dummy arguments are no longer assumed to potentially alias (overlap) other dummy arguments or COMMON areas when any of these are defined (assigned to) by Fortran code.

  This can result in faster and/or smaller programs when compiling with optimization enabled, though on some systems this effect is observed only when -fforce-addr also is specified.

  New options -falias-check, -fargument-alias, -fargument-noalias, and -fno-argument-noalias-global control the way g77 handles potential aliasing.

  See Aliasing Assumed To Work, for detailed information on why the new defaults might result in some programs no longer working the way they did when compiled by previous versions of g77.

• New option -fugly-assign specifies that the same memory locations are to be used to hold the values assigned by both statements I = 3 and ASSIGN 10 TO I, for example. (Normally, g77 uses a separate memory location to hold assigned statement labels.)

  See Ugly Assigned Labels, for more information.

• FORMAT and ENTRY statements now are allowed to precede IMPLICIT NONE statements.
• Enable full support of INTEGER(KIND=2) (often referred to as INTEGER*8) available in libf2c and f2c.h so that f2c users may make full use of its features via the g77 version of f2c.h and the INTEGER(KIND=2) support routines in the g77 version of libf2c.
• Improve g77 driver and libf2c so that g77 -v yields version information on the library.
• The SNGL and FLOAT intrinsics now are specific intrinsics, instead of synonyms for the generic intrinsic REAL.
• New intrinsics have been added. These are REALPART, IMAGPART, COMPLEX, LONG, and SHORT.
• A new group of intrinsics, gnu, has been added to contain the new REALPART, IMAGPART, and COMPLEX intrinsics. An old group, dcp, has been removed.

In 0.5.19:

• A temporary kludge option provides bare-bones information on COMMON and EQUIVALENCE members at debug time. See Options for Code Generation Conventions, for information on the -fdebug-kludge option.
• New -fonetrip option specifies FORTRAN-66-style one-trip DO loops.
• New -fno-silent option causes names of program units to be printed as they are compiled, in a fashion similar to UNIX f77 and f2c.
• New -fugly-assumed option specifies that arrays dimensioned via DIMENSION X(1), for example, are to be treated as assumed-size.
• New -fno-typeless-boz option specifies that non-decimal-radix constants using the prefixed-radix form (such as Z'1234') are to be interpreted as INTEGER(KIND=1) constants.
• New -ff66 option is a ``shorthand'' option that specifies behaviors considered appropriate for FORTRAN 66 programs.
• New -ff77 option is a ``shorthand'' option that specifies behaviors considered appropriate for UNIX f77 programs.
• New -fugly-comma and -fugly-logint options provided to perform some of what -fugly used to do. -fugly and -fno-ugly are now ``shorthand'' options, in that they do nothing more than enable (or disable) other -fugly-* options.
• Change code generation for list-directed I/O so it allows for new versions of libf2c that might return non-zero status codes for some operations previously assumed to always return zero.

  This change not only affects how IOSTAT= variables are set by list-directed I/O, it also affects whether END= and ERR= labels are reached by these operations.

• Add intrinsic support for new FTELL and FSEEK procedures in libf2c.
• Add options --help and --version to the g77 command, to conform to GNU coding guidelines. Also add printing of g77 version number when the --verbose (-v) option is used.

In 0.5.18:

• The BYTE and WORD statements now are supported, to a limited extent.
• INTEGER*1, INTEGER*2, INTEGER*8, and their LOGICAL equivalents, now are supported to a limited extent. Among the missing elements are complete intrinsic and constant support.
• Support automatic arrays in procedures. For example, REAL A(N), where A is not a dummy argument, specifies that A is an automatic array. The size of A is calculated from the value of N each time the procedure is called, that amount of space is allocated, and that space is freed when the procedure returns to its caller.
• Add -fno-zeros option, enabled by default, to reduce compile-time CPU and memory usage for code that provides initial zero values for variables and arrays.
• Introduce three new options that apply to all compilations by g77-aware GNU compilers----fmove-all-movables, -freduce-all-givs, and -frerun-loop-opt---which can improve the run-time performance of some programs.
• Replace much of the existing documentation with a single Info document.
• New option -fno-second-underscore.

In 0.5.17:

• The ERF() and ERFC() intrinsics now are generic intrinsics, mapping to ERF/DERF and ERFC/DERFC, respectively. Note: Use INTRINSIC ERF,ERFC in any code that might reference these as generic intrinsics, to improve the likelihood of diagnostics (instead of subtle run-time bugs) when using compilers that don't support these as intrinsics.
• New option -Wsurprising.
• DO loops with non-INTEGER variables now diagnosed only when -Wsurprising specified. Previously, this was diagnosed unless -fpedantic or -fugly was specified.

In 0.5.16:

• libf2c changed to output a leading zero (0) digit for floating-point values output via list-directed and formatted output (to bring g77 more into line with many existing Fortran implementations---the ANSI FORTRAN 77 standard leaves this choice to the implementation).
• libf2c no longer built with debugging information intact, making it much smaller.
• Automatic installation of the g77 command now works.
• Diagnostic messages now more informative, a la gcc, including messages like In function `foo': and In file included from...:.
• New group of intrinsics called unix, including ABORT, DERF, DERFC, ERF, ERFC, EXIT, FLUSH, GETARG, GETENV, SIGNAL, and SYSTEM.
• -funix-intrinsics-{delete,hide,disable,enable} options added.
• -fno-underscoring option added.
• --driver option added to the g77 command.
• Support for the gcc options -fident and -fno-ident added.
• g77 -v returns much more version info, making the submission of better bug reports easily.
• Many improvements to the g77 command to better fulfill its role as a front-end to the gcc driver. For example, g77 now recognizes --verbose as a verbose way of specifying -v.
• Compiling preprocessed (*.F and *.fpp) files now results in better diagnostics and debugging information, as the source-location info now is passed all the way through the compilation process instead of being lost.

The GNU Fortran Language

GNU Fortran supports a variety of extensions to, and dialects of, the Fortran language. Its primary base is the ANSI FORTRAN 77 standard, currently available on the network at {http://kumo.swcp.com/fortran/F77_std/f77_std.html} or in {ftp://ftp.ast.cam.ac.uk/pub/michael/}. It offers some extensions that are popular among users of UNIX f77 and f2c compilers, some that are popular among users of other compilers (such as Digital products), some that are popular among users of the newer Fortran 90 standard, and some that are introduced by GNU Fortran.

(If you need a text on Fortran, a few freely available electronic references have pointers from {http://www.fortran.com/fortran/Books/}.)

Part of what defines a particular implementation of a Fortran system, such as g77, is the particular characteristics of how it supports types, constants, and so on. Much of this is left up to the implementation by the various Fortran standards and accepted practice in the industry.

The GNU Fortran language is described below. Much of the material is organized along the same lines as the ANSI FORTRAN 77 standard itself.

See Other Dialects, for information on features g77 supports that are not part of the GNU Fortran language.

Note: This portion of the documentation definitely needs a lot of work!

Relationship to the ANSI FORTRAN 77 standard:

• Where GNU Fortran is headed.
• Degree of support for the standard.

Extensions to the ANSI FORTRAN 77 standard:

• Conformance
• Notation Used
• Terms and Concepts
• Characters Lines Sequence
• Data Types and Constants
• Expressions
• Specification Statements
• Control Statements
• Functions and Subroutines
• Scope and Classes of Names

Direction of Language Development

The purpose of the following description of the GNU Fortran language is to promote wide portability of GNU Fortran programs.

GNU Fortran is an evolving language, due to the fact that g77 itself is in beta test. Some current features of the language might later be redefined as dialects of Fortran supported by g77 when better ways to express these features are added to g77, for example. Such features would still be supported by g77, but would be available only when one or more command-line options were used.

The GNU Fortran language is distinct from the GNU Fortran compilation system (g77).

For example, g77 supports various dialects of Fortran---in a sense, these are languages other than GNU Fortran---though its primary purpose is to support the GNU Fortran language, which also is described in its documentation and by its implementation.

On the other hand, non-GNU compilers might offer support for the GNU Fortran language, and are encouraged to do so.

Currently, the GNU Fortran language is a fairly fuzzy object. It represents something of a cross between what g77 accepts when compiling using the prevailing defaults and what this document describes as being part of the language.

Future versions of g77 are expected to clarify the definition of the language in the documentation. Often, this will mean adding new features to the language, in the form of both new documentation and new support in g77. However, it might occasionally mean removing a feature from the language itself to ``dialect'' status. In such a case, the documentation would be adjusted to reflect the change, and g77 itself would likely be changed to require one or more command-line options to continue supporting the feature.

The development of the GNU Fortran language is intended to strike a balance between:

• Serving as a mostly-upwards-compatible language from the de facto UNIX Fortran dialect as supported by f77.
• Offering new, well-designed language features. Attributes of such features include not making existing code any harder to read (for those who might be unaware that the new features are not in use) and not making state-of-the-art compilers take longer to issue diagnostics, among others.
• Supporting existing, well-written code without gratuitously rejecting non-standard constructs, regardless of the origin of the code (its dialect).
• Offering default behavior and command-line options to reduce and, where reasonable, eliminate the need for programmers to make any modifications to code that already works in existing production environments.
• Diagnosing constructs that have different meanings in different systems, languages, and dialects, while offering clear, less ambiguous ways to express each of the different meanings so programmers can change their code appropriately.

One of the biggest practical challenges for the developers of the GNU Fortran language is meeting the sometimes contradictory demands of the above items.

For example, a feature might be widely used in one popular environment, but the exact same code that utilizes that feature might not work as expected---perhaps it might mean something entirely different---in another popular environment.

Traditionally, Fortran compilers---even portable ones---have solved this problem by simply offering the appropriate feature to users of the respective systems. This approach treats users of various Fortran systems and dialects as remote ``islands'', or camps, of programmers, and assume that these camps rarely come into contact with each other (or, especially, with each other's code).

Project GNU takes a radically different approach to software and language design, in that it assumes that users of GNU software do not necessarily care what kind of underlying system they are using, regardless of whether they are using software (at the user-interface level) or writing it (for example, writing Fortran or C code).

As such, GNU users rarely need consider just what kind of underlying hardware (or, in many cases, operating system) they are using at any particular time. They can use and write software designed for a general-purpose, widely portable, heteregenous environment---the GNU environment.

In line with this philosophy, GNU Fortran must evolve into a product that is widely ported and portable not only in the sense that it can be successfully built, installed, and run by users, but in the larger sense that its users can use it in the same way, and expect largely the same behaviors from it, regardless of the kind of system they are using at any particular time.

This approach constrains the solutions g77 can use to resolve conflicts between various camps of Fortran users. If these two camps disagree about what a particular construct should mean, g77 cannot simply be changed to treat that particular construct as having one meaning without comment (such as a warning), lest the users expecting it to have the other meaning are unpleasantly surprised that their code misbehaves when executed.

The use of the ASCII backslash character in character constants is an excellent (and still somewhat unresolved) example of this kind of controversy. See Backslash in Constants. Other examples are likely to arise in the future, as g77 developers strive to improve its ability to accept an ever-wider variety of existing Fortran code without requiring significant modifications to said code.

Development of GNU Fortran is further constrained by the desire to avoid requiring programmers to change their code. This is important because it allows programmers, administrators, and others to more faithfully evaluate and validate g77 (as an overall product and as new versions are distributed) without having to support multiple versions of their programs so that they continue to work the same way on their existing systems (non-GNU perhaps, but possibly also earlier versions of g77).

ANSI FORTRAN 77 Standard Support

GNU Fortran supports ANSI FORTRAN 77 with the following caveats. In summary, the only ANSI FORTRAN 77 features g77 doesn't support are those that are probably rarely used in actual code, some of which are explicitly disallowed by the Fortran 90 standard.

• CHAR*(*) CFUNC restriction.
• CHAR*(*) CFUNC restriction.
• No ((···, I=···), I=···).
• No (A, I=1, 1).

No Passing External Assumed-length

g77 disallows passing of an external procedure as an actual argument if the procedure's type is declared CHARACTER*(*). For example:

CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END

It isn't clear whether the standard considers this conforming.

No Passing Dummy Assumed-length

g77 disallows passing of a dummy procedure as an actual argument if the procedure's type is declared CHARACTER*(*).

SUBROUTINE BAR(CFUNC)
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END

It isn't clear whether the standard considers this conforming.

No Pathological Implied-DO

The DO variable for an implied-DO construct in a DATA statement may not be used as the DO variable for an outer implied-DO construct. For example, this fragment is disallowed by g77:

DATA ((A(I, I), I= 1, 10), I= 1, 10) /···/

This also is disallowed by Fortran 90, as it offers no additional capabilities and would have a variety of possible meanings.

Note that it is very unlikely that any production Fortran code tries to use this unsupported construct.

No Useless Implied-DO

An array element initializer in an implied-DO construct in a DATA statement must contain at least one reference to the DO variables of each outer implied-DO construct. For example, this fragment is disallowed by g77:

DATA (A, I= 1, 1) /1./

This also is disallowed by Fortran 90, as FORTRAN 77's more permissive requirements offer no additional capabilities. However, g77 doesn't necessarily diagnose all cases where this requirement is not met.

Note that it is very unlikely that any production Fortran code tries to use this unsupported construct.

Conformance

(The following information augments or overrides the information in Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 1 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

The definition of the GNU Fortran language is akin to that of the ANSI FORTRAN 77 language in that it does not generally require conforming implementations to diagnose cases where programs do not conform to the language.

However, g77 as a compiler is being developed in a way that is intended to enable it to diagnose such cases in an easy-to-understand manner.

A program that conforms to the GNU Fortran language should, when compiled, linked, and executed using a properly installed g77 system, perform as described by the GNU Fortran language definition. Reasons for different behavior include, among others:

• Use of resources (memory---heap, stack, and so on; disk space; CPU time; etc.) exceeds those of the system.
• Range and/or precision of calculations required by the program exceeds that of the system.
• Excessive reliance on behaviors that are system-dependent (non-portable Fortran code).
• Bugs in the program.
• Bug in g77.
• Bugs in the system.

Despite these ``loopholes'', the availability of a clear specification of the language of programs submitted to g77, as this document is intended to provide, is considered an important aspect of providing a robust, clean, predictable Fortran implementation.

The definition of the GNU Fortran language, while having no special legal status, can therefore be viewed as a sort of contract, or agreement. This agreement says, in essence, ``if you write a program in this language, and run it in an environment (such as a g77 system) that supports this language, the program should behave in a largely predictable way''.

Notation Used in This Chapter

(The following information augments or overrides the information in Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 1 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

In this chapter, ``must'' denotes a requirement, ``may'' denotes permission, and ``must not'' and ``may not'' denote prohibition. Terms such as ``might'', ``should'', and ``can'' generally add little or nothing in the way of weight to the GNU Fortran language itself, but are used to explain or illustrate the language.

For example:

``The FROBNITZ statement must precede all executable
statements in a program unit, and may not specify any dummy
arguments.  It may specify local or common variables and arrays.
Its use should be limited to portions of the program designed to
be non-portable and system-specific, because it might cause the
containing program unit to behave quite differently on different
systems.''

Insofar as the GNU Fortran language is specified, the requirements and permissions denoted by the above sample statement are limited to the placement of the statement and the kinds of things it may specify. The rest of the statement---the content regarding non-portable portions of the program and the differing behavior of program units containing the FROBNITZ statement---does not pertain the GNU Fortran language itself. That content offers advice and warnings about the FROBNITZ statement.

Remember: The GNU Fortran language definition specifies both what constitutes a valid GNU Fortran program and how, given such a program, a valid GNU Fortran implementation is to interpret that program.

It is not incumbent upon a valid GNU Fortran implementation to behave in any particular way, any consistent way, or any predictable way when it is asked to interpret input that is not a valid GNU Fortran program.

Such input is said to have undefined behavior when interpreted by a valid GNU Fortran implementation, though an implementation may choose to specify behaviors for some cases of inputs that are not valid GNU Fortran programs.

Other notation used herein is that of the GNU texinfo format, which is used to generate printed hardcopy, on-line hypertext (Info), and on-line HTML versions, all from a single source document. This notation is used as follows:

• Keywords defined by the GNU Fortran language are shown in uppercase, as in: COMMON, INTEGER, and BLOCK DATA.

  Note that, in practice, many Fortran programs are written in lowercase---uppercase is used in this manual as a means to readily distinguish keywords and sample Fortran-related text from the prose in this document.

• Portions of actual sample program, input, or output text look like this: Actual program text.

  Generally, uppercase is used for all Fortran-specific and Fortran-related text, though this does not always include literal text within Fortran code.

  For example: PRINT *, 'My name is Bob'.

• A metasyntactic variable---that is, a name used in this document to serve as a placeholder for whatever text is used by the user or programmer--appears as shown in the following example:

  ``The INTEGER ivar statement specifies that ivar is a variable or array of type INTEGER.''

  In the above example, any valid text may be substituted for the metasyntactic variable ivar to make the statement apply to a specific instance, as long as the same text is substituted for both occurrences of ivar.

• Ellipses (``···'') are used to indicate further text that is either unimportant or expanded upon further, elsewhere.
• Names of data types are in the style of Fortran 90, in most cases.

  See Kind Notation, for information on the relationship between Fortran 90 nomenclature (such as INTEGER(KIND=1)) and the more traditional, less portably concise nomenclature (such as INTEGER*4).

Fortran Terms and Concepts

(The following information augments or overrides the information in Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 2 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• Syntactic Items
• Statements Comments Lines
• Scope of Names and Labels

Syntactic Items

(Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)

In GNU Fortran, a symbolic name is at least one character long, and has no arbitrary upper limit on length. However, names of entities requiring external linkage (such as external functions, external subroutines, and COMMON areas) might be restricted to some arbitrary length by the system. Such a restriction is no more constrained than that of one through six characters.

Underscores (_) are accepted in symbol names after the first character (which must be a letter).

Statements, Comments, and Lines

(Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)

Use of an exclamation point (!) to begin a trailing comment (a comment that extends to the end of the same source line) is permitted under the following conditions:

• The exclamation point does not appear in column 6. Otherwise, it is treated as an indicator of a continuation line.
• The exclamation point appears outside a character or hollerith constant. Otherwise, the exclamation point is considered part of the constant.
• The exclamation point appears to the left of any other possible trailing comment. That is, a trailing comment may contain exclamation points in their commentary text.

Use of a semicolon (;) as a statement separator is permitted under the following conditions:

• The semicolon appears outside a character or hollerith constant. Otherwise, the semicolon is considered part of the constant.
• The semicolon appears to the left of a trailing comment. Otherwise, the semicolon is considered part of that comment.
• Neither a logical IF statement nor a non-construct WHERE statement (a Fortran 90 feature) may be followed (in the same, possibly continued, line) by a semicolon used as a statement separator.

  This restriction avoids the confusion that can result when reading a line such as:

  IF (VALIDP) CALL FOO; CALL BAR
  

  Some readers might think the CALL BAR is executed only if VALIDP is .TRUE., while others might assume its execution is unconditional.

  (At present, g77 does not diagnose code that violates this restriction.)

Scope of Symbolic Names and Statement Labels

(Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)

Included in the list of entities that have a scope of a program unit are construct names (a Fortran 90 feature). See Construct Names, for more information.

Characters, Lines, and Execution Sequence

(The following information augments or overrides the information in Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 3 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• Character Set
• Lines
• Continuation Line
• Statements
• Statement Labels
• Order
• INCLUDE

GNU Fortran Character Set

(Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)

Letters include uppercase letters (the twenty-six characters of the English alphabet) and lowercase letters (their lowercase equivalent). Generally, lowercase letters may be used in place of uppercase letters, though in character and hollerith constants, they are distinct.

Special characters include:

• Semicolon (;)
• Exclamation point (!)
• Double quote (")
• Backslash (\)
• Question mark (?)
• Hash mark (#)
• Ampersand (&)
• Percent sign (%)
• Underscore (_)
• Open angle (<)
• Close angle (>)
• The FORTRAN 77 special characters (SPC, =, +, -, *, /, (, ), ,, ., $, ', and :)

Note that this document refers to SPC as space, while X3.9-1978 FORTRAN 77 refers to it as blank.

Lines

(Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)

The way a Fortran compiler views source files depends entirely on the implementation choices made for the compiler, since those choices are explicitly left to the implementation by the published Fortran standards.

The GNU Fortran language mandates a view applicable to UNIX-like text files---files that are made up of an arbitrary number of lines, each with an arbitrary number of characters (sometimes called stream-based files).

This view does not apply to types of files that are specified as having a particular number of characters on every single line (sometimes referred to as record-based files).

Because a ``line in a program unit is a sequence of 72 characters'', to quote X3.9-1978, the GNU Fortran language specifies that a stream-based text file is translated to GNU Fortran lines as follows:

• A newline in the file is the character that represents the end of a line of text to the underlying system. For example, on ASCII-based systems, a newline is the NL character, which has ASCII value 12 (decimal).
• Each newline in the file serves to end the line of text that precedes it (and that does not contain a newline).
• The end-of-file marker (EOF) also serves to end the line of text that precedes it (and that does not contain a newline).
• Any line of text that is shorter than 72 characters is padded to that length with spaces (called ``blanks'' in the standard).
• Any line of text that is longer than 72 characters is truncated to that length, but the truncated remainder must consist entirely of spaces.
• Characters other than newline and the GNU Fortran character set are invalid.

For the purposes of the remainder of this description of the GNU Fortran language, the translation described above has already taken place, unless otherwise specified.

The result of the above translation is that the source file appears, in terms of the remainder of this description of the GNU Fortran language, as if it had an arbitrary number of 72-character lines, each character being among the GNU Fortran character set.

For example, if the source file itself has two newlines in a row, the second newline becomes, after the above translation, a single line containing 72 spaces.

Continuation Line

(Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)

A continuation line is any line that both

• Contains a continuation character, and
• Contains only spaces in columns 1 through 5

A continuation character is any character of the GNU Fortran character set other than space (SPC) or zero (0) in column 6, or a digit (0 through 9) in column 7 through 72 of a line that has only spaces to the left of that digit.

The continuation character is ignored as far as the content of the statement is concerned.

The GNU Fortran language places no limit on the number of continuation lines in a statement. In practice, the limit depends on a variety of factors, such as available memory, statement content, and so on, but no GNU Fortran system may impose an arbitrary limit.

Statements

(Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)

Statements may be written using an arbitrary number of continuation lines.

Statements may be separated using the semicolon (;), except that the logical IF and non-construct WHERE statements may not be separated from subsequent statements using only a semicolon as statement separator.

The END PROGRAM, END SUBROUTINE, END FUNCTION, and END BLOCK DATA statements are alternatives to the END statement. These alternatives may be written as normal statements---they are not subject to the restrictions of the END statement.

However, no statement other than END may have an initial line that appears to be an END statement---even END PROGRAM, for example, must not be written as:

      END
     &PROGRAM

Statement Labels

(Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)

A statement separated from its predecessor via a semicolon may be labeled as follows:

• The semicolon is followed by the label for the statement, which in turn follows the label.
• The label must be no more than five digits in length.
• The first digit of the label for the statement is not the first non-space character on a line. Otherwise, that character is treated as a continuation character.

A statement may have only one label defined for it.

Order of Statements and Lines

(Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)

Generally, DATA statements may precede executable statements. However, specification statements pertaining to any entities initialized by a DATA statement must precede that DATA statement. For example, after DATA I/1/, INTEGER I is not permitted, but INTEGER J is permitted.

The last line of a program unit may be an END statement, or may be:

• An END PROGRAM statement, if the program unit is a main program.
• An END SUBROUTINE statement, if the program unit is a subroutine.
• An END FUNCTION statement, if the program unit is a function.
• An END BLOCK DATA statement, if the program unit is a block data.

Including Source Text

Additional source text may be included in the processing of the source file via the INCLUDE directive:

INCLUDE filename

The source text to be included is identified by filename, which is a literal GNU Fortran character constant. The meaning and interpretation of filename depends on the implementation, but typically is a filename.

(g77 treats it as a filename that it searches for in the current directory and/or directories specified via the -I command-line option.)

The effect of the INCLUDE directive is as if the included text directly replaced the directive in the source file prior to interpretation of the program. Included text may itself use INCLUDE. The depth of nested INCLUDE references depends on the implementation, but typically is a positive integer.

This virtual replacement treats the statements and INCLUDE directives in the included text as syntactically distinct from those in the including text.

Therefore, the first non-comment line of the included text must not be a continuation line. The included text must therefore have, after the non-comment lines, either an initial line (statement), an INCLUDE directive, or nothing (the end of the included text).

Similarly, the including text may end the INCLUDE directive with a semicolon or the end of the line, but it cannot follow an INCLUDE directive at the end of its line with a continuation line. Thus, the last statement in an included text may not be continued.

Any statements between two INCLUDE directives on the same line are treated as if they appeared in between the respective included texts. For example:

INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM

If the text included by INCLUDE 'A' constitutes a PRINT *, 'A' statement and the text included by INCLUDE 'C' constitutes a PRINT *, 'C' statement, then the output of the above sample program would be

A
B
C

(with suitable allowances for how an implementation defines its handling of output).

Included text must not include itself directly or indirectly, regardless of whether the filename used to reference the text is the same.

Note that INCLUDE is not a statement. As such, it is neither a non-executable or executable statement. However, if the text it includes constitutes one or more executable statements, then the placement of INCLUDE is subject to effectively the same restrictions as those on executable statements.

An INCLUDE directive may be continued across multiple lines as if it were a statement. This permits long names to be used for filename.

Data Types and Constants

(The following information augments or overrides the information in Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 4 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

To more concisely express the appropriate types for entities, this document uses the more concise Fortran 90 nomenclature such as INTEGER(KIND=1) instead of the more traditional, but less portably concise, byte-size-based nomenclature such as INTEGER*4, wherever reasonable.

When referring to generic types---in contexts where the specific precision and range of a type are not important---this document uses the generic type names INTEGER, LOGICAL, REAL, COMPLEX, and CHARACTER.

In some cases, the context requires specification of a particular type. This document uses the KIND= notation to accomplish this throughout, sometimes supplying the more traditional notation for clarification, though the traditional notation might not work the same way on all GNU Fortran implementations.

Use of KIND= makes this document more concise because g77 is able to define values for KIND= that have the same meanings on all systems, due to the way the Fortran 90 standard specifies these values are to be used.

(In particular, that standard permits an implementation to arbitrarily assign nonnegative values. There are four distinct sets of assignments: one to the CHARACTER type; one to the INTEGER type; one to the LOGICAL type; and the fourth to both the REAL and COMPLEX types. Implementations are free to assign these values in any order, leave gaps in the ordering of assignments, and assign more than one value to a representation.)

This makes KIND= values superior to the values used in non-standard statements such as INTEGER*4, because the meanings of the values in those statements vary from machine to machine, compiler to compiler, even operating system to operating system.

However, use of KIND= is not generally recommended when writing portable code (unless, for example, the code is going to be compiled only via g77, which is a widely ported compiler). GNU Fortran does not yet have adequate language constructs to permit use of KIND= in a fashion that would make the code portable to Fortran 90 implementations; and, this construct is known to not be accepted by many popular FORTRAN 77 implementations, so it cannot be used in code that is to be ported to those.

The distinction here is that this document is able to use specific values for KIND= to concisely document the types of various operations and operands.

A Fortran program should use the FORTRAN 77 designations for the appropriate GNU Fortran types---such as INTEGER for INTEGER(KIND=1), REAL for REAL(KIND=1), and DOUBLE COMPLEX for COMPLEX(KIND=2)---and, where no such designations exist, make use of appropriate techniques (preprocessor macros, parameters, and so on) to specify the types in a fashion that may be easily adjusted to suit each particular implementation to which the program is ported. (These types generally won't need to be adjusted for ports of g77.)

Further details regarding GNU Fortran data types and constants are provided below.

• Types
• Constants
• Integer Type
• Character Type

Data Types

(Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)

GNU Fortran supports these types:

1. Integer (generic type INTEGER)
2. Real (generic type REAL)
3. Double precision
4. Complex (generic type COMPLEX)
5. Logical (generic type LOGICAL)
6. Character (generic type CHARACTER)
7. Double Complex

(The types numbered 1 through 6 above are standard FORTRAN 77 types.)

The generic types shown above are referred to in this document using only their generic type names. Such references usually indicate that any specific type (kind) of that generic type is valid.

For example, a context described in this document as accepting the COMPLEX type also is likely to accept the DOUBLE COMPLEX type.

The GNU Fortran language supports three ways to specify a specific kind of a generic type.

• As in DOUBLE COMPLEX.
• As in INTEGER*4.
• As in INTEGER(KIND=1).

Double Notation

The GNU Fortran language supports two uses of the keyword DOUBLE to specify a specific kind of type:

• DOUBLE PRECISION, equivalent to REAL(KIND=2)
• DOUBLE COMPLEX, equivalent to COMPLEX(KIND=2)

Use one of the above forms where a type name is valid.

While use of this notation is popular, it doesn't scale well in a language or dialect rich in intrinsic types, as is the case for the GNU Fortran language (especially planned future versions of it).

After all, one rarely sees type names such as DOUBLE INTEGER, QUADRUPLE REAL, or QUARTER INTEGER. Instead, INTEGER*8, REAL*16, and INTEGER*1 often are substituted for these, respectively, even though they do not always have the same meanings on all systems. (And, the fact that DOUBLE REAL does not exist as such is an inconsistency.)

Therefore, this document uses ``double notation'' only on occasion for the benefit of those readers who are accustomed to it.

Star Notation

The following notation specifies the storage size for a type:

generic-type*n

generic-type must be a generic type---one of INTEGER, REAL, COMPLEX, LOGICAL, or CHARACTER. n must be one or more digits comprising a decimal integer number greater than zero.

Use the above form where a type name is valid.

The *n notation specifies that the amount of storage occupied by variables and array elements of that type is n times the storage occupied by a CHARACTER*1 variable.

This notation might indicate a different degree of precision and/or range for such variables and array elements, and the functions that return values of types using this notation. It does not limit the precision or range of values of that type in any particular way---use explicit code to do that.

Further, the GNU Fortran language requires no particular values for n to be supported by an implementation via the *n notation. g77 supports INTEGER*1 (as INTEGER(KIND=3)) on all systems, for example, but not all implementations are required to do so, and g77 is known to not support REAL*1 on most (or all) systems.

As a result, except for generic-type of CHARACTER, uses of this notation should be limited to isolated portions of a program that are intended to handle system-specific tasks and are expected to be non-portable.

(Standard FORTRAN 77 supports the *n notation for only CHARACTER, where it signifies not only the amount of storage occupied, but the number of characters in entities of that type. However, almost all Fortran compilers have supported this notation for generic types, though with a variety of meanings for n.)

Specifications of types using the *n notation always are interpreted as specifications of the appropriate types described in this document using the KIND=n notation, described below.

While use of this notation is popular, it doesn't serve well in the context of a widely portable dialect of Fortran, such as the GNU Fortran language.

For example, even on one particular machine, two or more popular Fortran compilers might well disagree on the size of a type declared INTEGER*2 or REAL*16. Certainly there is known to be disagreement over such things among Fortran compilers on different systems.

Further, this notation offers no elegant way to specify sizes that are not even multiples of the ``byte size'' typically designated by INTEGER*1. Use of ``absurd'' values (such as INTEGER*1000) would certainly be possible, but would perhaps be stretching the original intent of this notation beyond the breaking point in terms of widespread readability of documentation and code making use of it.

Therefore, this document uses ``star notation'' only on occasion for the benefit of those readers who are accustomed to it.

Kind Notation

The following notation specifies the kind-type selector of a type:

generic-type(KIND=n)

Use the above form where a type name is valid.

generic-type must be a generic type---one of INTEGER, REAL, COMPLEX, LOGICAL, or CHARACTER. n must be an integer initialization expression that is a positive, nonzero value.

Programmers are discouraged from writing these values directly into their code. Future versions of the GNU Fortran language will offer facilities that will make the writing of code portable to g77 and Fortran 90 implementations simpler.

However, writing code that ports to existing FORTRAN 77 implementations depends on avoiding the KIND= construct.

The KIND= construct is thus useful in the context of GNU Fortran for two reasons:

• It provides a means to specify a type in a fashion that is portable across all GNU Fortran implementations (though not other FORTRAN 77 and Fortran 90 implementations).
• It provides a sort of Rosetta stone for this document to use to concisely describe the types of various operations and operands.

The values of n in the GNU Fortran language are assigned using a scheme that:

• Attempts to maximize the ability of readers of this document to quickly familiarize themselves with assignments for popular types
• Provides a unique value for each specific desired meaning
• Provides a means to automatically assign new values so they have a ``natural'' relationship to existing values, if appropriate, or, if no such relationship exists, will not interfere with future values assigned on the basis of such relationships
• Avoids using values that are similar to values used in the existing, popular *n notation, to prevent readers from expecting that these implied correspondences work on all GNU Fortran implementations

The assignment system accomplishes this by assigning to each ``fundamental meaning'' of a specific type a unique prime number. Combinations of fundamental meanings---for example, a type that is two times the size of some other type---are assigned values of n that are the products of the values for those fundamental meanings.

A prime value of n is never given more than one fundamental meaning, to avoid situations where some code or system cannot reasonably provide those meanings in the form of a single type.

The values of n assigned so far are:

KIND=0


This value is reserved for future use.

The planned future use is for this value to designate, explicitly, context-sensitive kind-type selection. For example, the expression 1D0 * 0.1_0 would be equivalent to 1D0 * 0.1D0.

KIND=1


This corresponds to the default types for REAL, INTEGER, LOGICAL, COMPLEX, and CHARACTER, as appropriate.

These are the ``default'' types described in the Fortran 90 standard, though that standard does not assign any particular KIND= value to these types.

(Typically, these are REAL*4, INTEGER*4, LOGICAL*4, and COMPLEX*8.)

KIND=2


This corresponds to types that occupy twice as much storage as the default types. REAL(KIND=2) is DOUBLE PRECISION (typically REAL*8), COMPLEX(KIND=2) is DOUBLE COMPLEX (typically COMPLEX*16),

These are the ``double precision'' types described in the Fortran 90 standard, though that standard does not assign any particular KIND= value to these types.

n of 4 thus corresponds to types that occupy four times as much storage as the default types, n of 8 to types that occupy eight times as much storage, and so on.

The INTEGER(KIND=2) and LOGICAL(KIND=2) types are not necessarily supported by every GNU Fortran implementation.

KIND=3


This corresponds to types that occupy as much storage as the default CHARACTER type, which is the same effective type as CHARACTER(KIND=1) (making that type effectively the same as CHARACTER(KIND=3)).

(Typically, these are INTEGER*1 and LOGICAL*1.)

n of 6 thus corresponds to types that occupy twice as much storage as the n=3 types, n of 12 to types that occupy four times as much storage, and so on.

These are not necessarily supported by every GNU Fortran implementation.

KIND=5


This corresponds to types that occupy half the storage as the default (n=1) types.

(Typically, these are INTEGER*2 and LOGICAL*2.)

n of 25 thus corresponds to types that occupy one-quarter as much storage as the default types.

These are not necessarily supported by every GNU Fortran implementation.

KIND=7


This is valid only as INTEGER(KIND=7) and denotes the INTEGER type that has the smallest storage size that holds a pointer on the system.

A pointer representable by this type is capable of uniquely addressing a CHARACTER*1 variable, array, array element, or substring.

(Typically this is equivalent to INTEGER*4 or, on 64-bit systems, INTEGER*8. In a compatible C implementation, it typically would be the same size and semantics of the C type void *.)

Note that these are proposed correspondences and might change in future versions of g77---avoid writing code depending on them while g77, and therefore the GNU Fortran language it defines, is in beta testing.

Values not specified in the above list are reserved to future versions of the GNU Fortran language.

Implementation-dependent meanings will be assigned new, unique prime numbers so as to not interfere with other implementation-dependent meanings, and offer the possibility of increasing the portability of code depending on such types by offering support for them in other GNU Fortran implementations.

Other meanings that might be given unique values are:

• Types that make use of only half their storage size for representing precision and range.

  For example, some compilers offer options that cause INTEGER types to occupy the amount of storage that would be needed for INTEGER(KIND=2) types, but the range remains that of INTEGER(KIND=1).

• The IEEE single floating-point type.
• Types with a specific bit pattern (endianness), such as the little-endian form of INTEGER(KIND=1). These could permit, conceptually, use of portable code and implementations on data files written by existing systems.

Future prime numbers should be given meanings in as incremental a fashion as possible, to allow for flexibility and expressiveness in combining types.

For example, instead of defining a prime number for little-endian IEEE doubles, one prime number might be assigned the meaning ``little-endian'', another the meaning ``IEEE double'', and the value of n for a little-endian IEEE double would thus naturally be the product of those two respective assigned values. (It could even be reasonable to have IEEE values result from the products of prime values denoting exponent and fraction sizes and meanings, hidden bit usage, availability and representations of special values such as subnormals, infinities, and Not-A-Numbers (NaNs), and so on.)

This assignment mechanism, while not inherently required for future versions of the GNU Fortran language, is worth using because it could ease management of the ``space'' of supported types much easier in the long run.

The above approach suggests a mechanism for specifying inheritance of intrinsic (built-in) types for an entire, widely portable product line. It is certainly reasonable that, unlike programmers of other languages offering inheritance mechanisms that employ verbose names for classes and subclasses, along with graphical browsers to elucidate the relationships, Fortran programmers would employ a mechanism that works by multiplying prime numbers together and finding the prime factors of such products.

Most of the advantages for the above scheme have been explained above. One disadvantage is that it could lead to the defining, by the GNU Fortran language, of some fairly large prime numbers. This could lead to the GNU Fortran language being declared ``munitions'' by the United States Department of Defense.

Constants

(Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)

A typeless constant has one of the following forms:

'binary-digits'B
'octal-digits'O
'hexadecimal-digits'Z
'hexadecimal-digits'X

binary-digits, octal-digits, and hexadecimal-digits are nonempty strings of characters in the set 01, 01234567, and 0123456789ABCDEFabcdef, respectively. (The value for A (and a) is 10, for B and b is 11, and so on.)

Typeless constants have values that depend on the context in which they are used.

All other constants, called typed constants, are interpreted---converted to internal form---according to their inherent type. Thus, context is never a determining factor for the type, and hence the interpretation, of a typed constant. (All constants in the ANSI FORTRAN 77 language are typed constants.)

For example, 1 is always type INTEGER(KIND=1) in GNU Fortran (called default INTEGER in Fortran 90), 9.435784839284958 is always type REAL(KIND=1) (even if the additional precision specified is lost, and even when used in a REAL(KIND=2) context), 1E0 is always type REAL(KIND=2), and 1D0 is always type REAL(KIND=2).

Integer Type

(Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)

An integer constant also may have one of the following forms:

B'binary-digits'
O'octal-digits'
Z'hexadecimal-digits'
X'hexadecimal-digits'

binary-digits, octal-digits, and hexadecimal-digits are nonempty strings of characters in the set 01, 01234567, and 0123456789ABCDEFabcdef, respectively. (The value for A (and a) is 10, for B and b is 11, and so on.)

Character Type

(Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)

A character constant may be delimited by a pair of double quotes (") instead of apostrophes. In this case, an apostrophe within the constant represents a single apostrophe, while a double quote is represented in the source text of the constant by two consecutive double quotes with no intervening spaces.

A character constant may be empty (have a length of zero).

A character constant may include a substring specification, The value of such a constant is the value of the substring---for example, the value of 'hello'(3:5) is the same as the value of 'llo'.

Expressions

(The following information augments or overrides the information in Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 6 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• %LOC()

The %LOC() Construct

%LOC(arg)

The %LOC() construct is an expression that yields the value of the location of its argument, arg, in memory. The size of the type of the expression depends on the system---typically, it is equivalent to either INTEGER(KIND=1) or INTEGER(KIND=2), though it is actually type INTEGER(KIND=7).

The argument to %LOC() must be suitable as the left-hand side of an assignment statement. That is, it may not be a general expression involving operators such as addition, subtraction, and so on, nor may it be a constant.

Use of %LOC() is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions that deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler.

Do not depend on %LOC() returning a pointer that can be safely used to define (change) the argument. While this might work in some circumstances, it is hard to predict whether it will continue to work when a program (that works using this unsafe behavior) is recompiled using different command-line options or a different version of g77.

Generally, %LOC() is safe when used as an argument to a procedure that makes use of the value of the corresponding dummy argument only during its activation, and only when such use is restricted to referencing (reading) the value of the argument to %LOC().

Implementation Note: Currently, g77 passes arguments (those not passed using a construct such as %VAL()) by reference or descriptor, depending on the type of the actual argument. Thus, given INTEGER I, CALL FOO(I) would seem to mean the same thing as CALL FOO(%LOC(I)), and in fact might compile to identical code.

However, CALL FOO(%LOC(I)) emphatically means ``pass the address of I in memory''. While CALL FOO(I) might use that same approach in a particular version of g77, another version or compiler might choose a different implementation, such as copy-in/copy-out, to effect the desired behavior---and which will therefore not necessarily compile to the same code as would CALL FOO(%LOC(I)) using the same version or compiler.

See Debugging and Interfacing, for detailed information on how this particular version of g77 implements various constructs.

Specification Statements

(The following information augments or overrides the information in Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 8 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• NAMELIST
• DOUBLE COMPLEX

NAMELIST Statement

The NAMELIST statement, and related I/O constructs, are supported by the GNU Fortran language in essentially the same way as they are by f2c.

DOUBLE COMPLEX Statement

DOUBLE COMPLEX is a type-statement (and type) that specifies the type COMPLEX(KIND=2) in GNU Fortran.

Control Statements

(The following information augments or overrides the information in Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 11 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• DO WHILE
• END DO
• Construct Names
• CYCLE and EXIT

DO WHILE

The DO WHILE statement, a feature of both the MIL-STD 1753 and Fortran 90 standards, is provided by the GNU Fortran language.

END DO

The END DO statement is provided by the GNU Fortran language.

This statement is used in one of two ways:

• The Fortran 90 meaning, in which it specifies the termination point of a single DO loop started with a DO statement that specifies no termination label.
• The MIL-STD 1753 meaning, in which it specifies the termination point of one or more DO loops, all of which start with a DO statement that specify the label defined for the END DO statement.

  This kind of END DO statement is merely a synonym for CONTINUE, except it is permitted only when the statement is labeled and a target of one or more labeled DO loops.

  It is expected that this use of END DO will be removed from the GNU Fortran language in the future, though it is likely that it will long be supported by g77 as a dialect form.

Construct Names

The GNU Fortran language supports construct names as defined by the Fortran 90 standard. These names are local to the program unit and are defined as follows:

construct-name: block-statement

Here, construct-name is the construct name itself; its definition is connoted by the single colon (:); and block-statement is an IF, DO, or SELECT CASE statement that begins a block.

A block that is given a construct name must also specify the same construct name in its termination statement:

END block construct-name

Here, block must be IF, DO, or SELECT, as appropriate.

The CYCLE and EXIT Statements

The CYCLE and EXIT statements specify that the remaining statements in the current iteration of a particular active (enclosing) DO loop are to be skipped.

CYCLE specifies that these statements are skipped, but the END DO statement that marks the end of the DO loop be executed---that is, the next iteration, if any, is to be started. If the statement marking the end of the DO loop is not END DO---in other words, if the loop is not a block DO---the CYCLE statement does not execute that statement, but does start the next iteration (if any).

EXIT specifies that the loop specified by the DO construct is terminated.

The DO loop affected by CYCLE and EXIT is the innermost enclosing DO loop when the following forms are used:

CYCLE
EXIT

Otherwise, the following forms specify the construct name of the pertinent DO loop:

CYCLE construct-name
EXIT construct-name

CYCLE and EXIT can be viewed as glorified GO TO statements. However, they cannot be easily thought of as GO TO statements in obscure cases involving FORTRAN 77 loops. For example:

      DO 10 I = 1, 5
      DO 10 J = 1, 5
         IF (J .EQ. 5) EXIT
      DO 10 K = 1, 5
         IF (K .EQ. 3) CYCLE
10    PRINT *, 'I=', I, ' J=', J, ' K=', K
20    CONTINUE

In particular, neither the EXIT nor CYCLE statements above are equivalent to a GO TO statement to either label 10 or 20.

To understand the effect of CYCLE and EXIT in the above fragment, it is helpful to first translate it to its equivalent using only block DO loops:

      DO I = 1, 5
         DO J = 1, 5
            IF (J .EQ. 5) EXIT
            DO K = 1, 5
               IF (K .EQ. 3) CYCLE
10             PRINT *, 'I=', I, ' J=', J, ' K=', K
            END DO
         END DO
      END DO
20    CONTINUE

Adding new labels allows translation of CYCLE and EXIT to GO TO so they may be more easily understood by programmers accustomed to FORTRAN coding:

      DO I = 1, 5
         DO J = 1, 5
            IF (J .EQ. 5) GOTO 18
            DO K = 1, 5
               IF (K .EQ. 3) GO TO 12
10             PRINT *, 'I=', I, ' J=', J, ' K=', K
12          END DO
         END DO
18    END DO
20    CONTINUE

Thus, the CYCLE statement in the innermost loop skips over the PRINT statement as it begins the next iteration of the loop, while the EXIT statement in the middle loop ends that loop but not the outermost loop.

Functions and Subroutines

(The following information augments or overrides the information in Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 15 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• %VAL()
• %REF()
• %DESCR()
• Generics and Specifics
• REAL() and AIMAG() of Complex
• CMPLX() of DOUBLE PRECISION
• MIL-STD 1753
• f77/f2c Intrinsics
• Table of Intrinsic Functions

The %VAL() Construct

%VAL(arg)

The %VAL() construct specifies that an argument, arg, is to be passed by value, instead of by reference or descriptor.

%VAL() is restricted to actual arguments in invocations of external procedures.

Use of %VAL() is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions the deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler.

Implementation Note: Currently, g77 passes all arguments either by reference or by descriptor.

Thus, use of %VAL() tends to be restricted to cases where the called procedure is written in a language other than Fortran that supports call-by-value semantics. (C is an example of such a language.)

See Procedures (SUBROUTINE and FUNCTION), for detailed information on how this particular version of g77 passes arguments to procedures.

The %REF() Construct

%REF(arg)

The %REF() construct specifies that an argument, arg, is to be passed by reference, instead of by value or descriptor.

%REF() is restricted to actual arguments in invocations of external procedures.

Use of %REF() is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions the deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler.

Do not depend on %REF() supplying a pointer to the procedure being invoked. While that is a likely implementation choice, other implementation choices are available that preserve Fortran pass-by-reference semantics without passing a pointer to the argument, arg. (For example, a copy-in/copy-out implementation.)

Implementation Note: Currently, g77 passes all arguments (other than variables and arrays of type CHARACTER) by reference. Future versions of, or dialects supported by, g77 might not pass CHARACTER functions by reference.

Thus, use of %REF() tends to be restricted to cases where arg is type CHARACTER but the called procedure accesses it via a means other than the method used for Fortran CHARACTER arguments.

See Procedures (SUBROUTINE and FUNCTION), for detailed information on how this particular version of g77 passes arguments to procedures.

The %DESCR() Construct

%DESCR(arg)

The %DESCR() construct specifies that an argument, arg, is to be passed by descriptor, instead of by value or reference.

%DESCR() is restricted to actual arguments in invocations of external procedures.

Use of %DESCR() is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions the deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler.

Do not depend on %DESCR() supplying a pointer and/or a length passed by value to the procedure being invoked. While that is a likely implementation choice, other implementation choices are available that preserve the pass-by-reference semantics without passing a pointer to the argument, arg. (For example, a copy-in/copy-out implementation.)@ And, future versions of g77 might change the way descriptors are implemented, such as passing a single argument pointing to a record containing the pointer/length information instead of passing that same information via two arguments as it currently does.

Implementation Note: Currently, g77 passes all variables and arrays of type CHARACTER by descriptor. Future versions of, or dialects supported by, g77 might pass CHARACTER functions by descriptor as well.

Thus, use of %DESCR() tends to be restricted to cases where arg is not type CHARACTER but the called procedure accesses it via a means similar to the method used for Fortran CHARACTER arguments.

See Procedures (SUBROUTINE and FUNCTION), for detailed information on how this particular version of g77 passes arguments to procedures.

Generics and Specifics

The ANSI FORTRAN 77 language defines generic and specific intrinsics. In short, the distinctions are:

• Specific intrinsics have specific types for their arguments and a specific return type.
• Generic intrinsics are treated, on a case-by-case basis in the program's source code, as one of several possible specific intrinsics.

  Typically, a generic intrinsic has a return type that is determined by the type of one or more of its arguments.

The GNU Fortran language generalizes these concepts somewhat, especially by providing intrinsic subroutines and generic intrinsics that are treated as either a specific intrinsic subroutine or a specific intrinsic function (e.g. SECOND).

However, GNU Fortran avoids generalizing this concept to the point where existing code would be accepted as meaning something possibly different than what was intended.

For example, ABS is a generic intrinsic, so all working code written using ABS of an INTEGER argument expects an INTEGER return value. Similarly, all such code expects that ABS of an INTEGER*2 argument returns an INTEGER*2 return value.

Yet, IABS is a specific intrinsic that accepts only an INTEGER(KIND=1) argument. Code that passes something other than an INTEGER(KIND=1) argument to IABS is not valid GNU Fortran code, because it is not clear what the author intended.

For example, if J is INTEGER(KIND=6), IABS(J) is not defined by the GNU Fortran language, because the programmer might have used that construct to mean any of the following, subtly different, things:

• Convert J to INTEGER(KIND=1) first (as if IABS(INT(J)) had been written).
• Convert the result of the intrinsic to INTEGER(KIND=1) (as if INT(ABS(J)) had been written).
• No conversion (as if ABS(J) had been written).

The distinctions matter especially when types and values wider than INTEGER(KIND=1) (such as INTEGER(KIND=2)), or when operations performing more ``arithmetic'' than absolute-value, are involved.

The following sample program is not a valid GNU Fortran program, but might be accepted by other compilers. If so, the output is likely to be revealing in terms of how a given compiler treats intrinsics (that normally are specific) when they are given arguments that do not conform to their stated requirements:

      PROGRAM JCB002
C Version 1:
C Modified 1997-05-21 (Burley) to accommodate compilers that implement
C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
C
C Version 0:
C Written by James Craig Burley 1997-02-20.
C Contact via Internet email: burley@gnu.org
C
C Purpose:
C Determine how compilers handle non-standard IDIM
C on INTEGER*2 operands, which presumably can be
C extrapolated into understanding how the compiler
C generally treats specific intrinsics that are passed
C arguments not of the correct types.
C
C If your compiler implements INTEGER*2 and INTEGER
C as the same type, change all INTEGER*2 below to
C INTEGER*1.
C
      INTEGER*2 I0, I4
      INTEGER I1, I2, I3
      INTEGER*2 ISMALL, ILARGE
      INTEGER*2 ITOOLG, ITWO
      INTEGER*2 ITMP
      LOGICAL L2, L3, L4
C
C Find smallest INTEGER*2 number.
C
      ISMALL=0
 10   I0 = ISMALL-1
      IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
      ISMALL = I0
      GOTO 10
 20   CONTINUE
C
C Find largest INTEGER*2 number.
C
      ILARGE=0
 30   I0 = ILARGE+1
      IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
      ILARGE = I0
      GOTO 30
 40   CONTINUE
C
C Multiplying by two adds stress to the situation.
C
      ITWO = 2
C
C Need a number that, added to -2, is too wide to fit in I*2.
C
      ITOOLG = ISMALL
C
C Use IDIM the straightforward way.
C
      I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
C
C Calculate result for first interpretation.
C
      I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
C
C Calculate result for second interpretation.
C
      ITMP = ILARGE - ISMALL
      I3 = (INT (ITMP)) * ITWO + ITOOLG
C
C Calculate result for third interpretation.
C
      I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
C
C Print results.
C
      PRINT *, 'ILARGE=', ILARGE
      PRINT *, 'ITWO=', ITWO
      PRINT *, 'ITOOLG=', ITOOLG
      PRINT *, 'ISMALL=', ISMALL
      PRINT *, 'I1=', I1
      PRINT *, 'I2=', I2
      PRINT *, 'I3=', I3
      PRINT *, 'I4=', I4
      PRINT *
      L2 = (I1 .EQ. I2)
      L3 = (I1 .EQ. I3)
      L4 = (I1 .EQ. I4)
      IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
         PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
         STOP
      END IF
      IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
         PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
         STOP
      END IF
      IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
         PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
         STOP
      END IF
      PRINT *, 'Results need careful analysis.'
      END

No future version of the GNU Fortran language will likely permit specific intrinsic invocations with wrong-typed arguments (such as IDIM in the above example), since it has been determined that disagreements exist among many production compilers on the interpretation of such invocations. These disagreements strongly suggest that Fortran programmers, and certainly existing Fortran programs, disagree about the meaning of such invocations.

The first version of JCB002 didn't accommodate some compilers' treatment of INT(I1-I2) where I1 and I2 are INTEGER*2. In such a case, these compilers apparently convert both operands to INTEGER*4 and then do an INTEGER*4 subtraction, instead of doing an INTEGER*2 subtraction on the original values in I1 and I2.

However, the results of the careful analyses done on the outputs of programs compiled by these various compilers show that they all implement either Interp 1 or Interp 2 above.

Specifically, it is believed that the new version of JCB002 above will confirm that:

• Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5 f77 compilers all implement Interp 1.
• IRIX 5.3 f77 compiler implements Interp 2.
• Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3, and IRIX 6.1 f77 compilers all implement Interp 3.

If you get different results than the above for the stated compilers, or have results for other compilers that might be worth adding to the above list, please let us know the details (compiler product, version, machine, results, and so on).

REAL() and AIMAG() of Complex

The GNU Fortran language disallows REAL(expr) and AIMAG(expr), where expr is any COMPLEX type other than COMPLEX(KIND=1), except when they are used in the following way:

REAL(REAL(expr))
REAL(AIMAG(expr))

The above forms explicitly specify that the desired effect is to convert the real or imaginary part of expr, which might be some REAL type other than REAL(KIND=1), to type REAL(KIND=1), and have that serve as the value of the expression.

The GNU Fortran language offers clearly named intrinsics to extract the real and imaginary parts of a complex entity without any conversion:

REALPART(expr)
IMAGPART(expr)

To express the above using typical extended FORTRAN 77, use the following constructs (when expr is COMPLEX(KIND=2)):

DBLE(expr)
DIMAG(expr)

The FORTRAN 77 language offers no way to explicitly specify the real and imaginary parts of a complex expression of arbitrary type, apparently as a result of requiring support for only one COMPLEX type (COMPLEX(KIND=1)). The concepts of converting an expression to type REAL(KIND=1) and of extracting the real part of a complex expression were thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since they happened to have the exact same effect in that language (due to having only one COMPLEX type).

Note: When -ff90 is in effect, g77 treats REAL(expr), where expr is of type COMPLEX, as REALPART(expr), whereas with -fugly-complex -fno-f90 in effect, it is treated as REAL(REALPART(expr)).

See Ugly Complex Part Extraction, for more information.

CMPLX() of DOUBLE PRECISION

In accordance with Fortran 90 and at least some (perhaps all) other compilers, the GNU Fortran language defines CMPLX() as always returning a result that is type COMPLEX(KIND=1).

This means CMPLX(D1,D2), where D1 and D2 are REAL(KIND=2) (DOUBLE PRECISION), is treated as:

CMPLX(SNGL(D1), SNGL(D2))

(It was necessary for Fortran 90 to specify this behavior for DOUBLE PRECISION arguments, since that is the behavior mandated by FORTRAN 77.)

The GNU Fortran language also provides the DCMPLX() intrinsic, which is provided by some FORTRAN 77 compilers to construct a DOUBLE COMPLEX entity from of DOUBLE PRECISION operands. However, this solution does not scale well when more COMPLEX types (having various precisions and ranges) are offered by Fortran implementations.

Fortran 90 extends the CMPLX() intrinsic by adding an extra argument used to specify the desired kind of complex result. However, this solution is somewhat awkward to use, and g77 currently does not support it.

The GNU Fortran language provides a simple way to build a complex value out of two numbers, with the precise type of the value determined by the types of the two numbers (via the usual type-promotion mechanism):

COMPLEX(real, imag)

When real and imag are the same REAL types, COMPLEX() performs no conversion other than to put them together to form a complex result of the same (complex version of real) type.

See Complex Intrinsic, for more information.

MIL-STD 1753 Support

The GNU Fortran language includes the MIL-STD 1753 intrinsics BTEST, IAND, IBCLR, IBITS, IBSET, IEOR, IOR, ISHFT, ISHFTC, MVBITS, and NOT.

f77/f2c Intrinsics

The bit-manipulation intrinsics supported by traditional f77 and by f2c are available in the GNU Fortran language. These include AND, LSHIFT, OR, RSHIFT, and XOR.

Also supported are the intrinsics CDABS, CDCOS, CDEXP, CDLOG, CDSIN, CDSQRT, DCMPLX, DCONJG, DFLOAT, DIMAG, DREAL, and IMAG, ZABS, ZCOS, ZEXP, ZLOG, ZSIN, and ZSQRT.

Table of Intrinsic Functions

(Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)

The GNU Fortran language adds various functions, subroutines, types, and arguments to the set of intrinsic functions in ANSI FORTRAN 77. The complete set of intrinsics supported by the GNU Fortran language is described below.

Note that a name is not treated as that of an intrinsic if it is specified in an EXTERNAL statement in the same program unit; if a command-line option is used to disable the groups to which the intrinsic belongs; or if the intrinsic is not named in an INTRINSIC statement and a command-line option is used to hide the groups to which the intrinsic belongs.

So, it is recommended that any reference in a program unit to an intrinsic procedure that is not a standard FORTRAN 77 intrinsic be accompanied by an appropriate INTRINSIC statement in that program unit. This sort of defensive programming makes it more likely that an implementation will issue a diagnostic rather than generate incorrect code for such a reference.

The terminology used below is based on that of the Fortran 90 standard, so that the text may be more concise and accurate:

• OPTIONAL means the argument may be omitted.
• A-1, A-2, ···, A-n means more than one argument (generally named A) may be specified.
• scalar means the argument must not be an array (must be a variable or array element, or perhaps a constant if expressions are permitted).
• DIMENSION(4) means the argument must be an array having 4 elements.
• INTENT(IN) means the argument must be an expression (such as a constant or a variable that is defined upon invocation of the intrinsic).
• INTENT(OUT) means the argument must be definable by the invocation of the intrinsic (that is, must not be a constant nor an expression involving operators other than array reference and substring reference).
• INTENT(INOUT) means the argument must be defined prior to, and definable by, invocation of the intrinsic (a combination of the requirements of INTENT(IN) and INTENT(OUT).
• See Kind Notation for explanation of KIND.

(Note that the empty lines appearing in the menu below are not intentional---they result from a bug in the GNU makeinfo program···a program that, if it did not exist, would leave this document in far worse shape!)

• Abort the program.
• Absolute value.
• Check file accessibility.
• ASCII character from code.
• Arc cosine.
• (Reserved for future use.)
• (Reserved for future use.)
• Convert/extract imaginary part of complex.
• Truncate to whole number.
• Execute a routine after a given delay.
• (Reserved for future use.)
• (Reserved for future use.)
• Natural logarithm (archaic).
• Natural logarithm (archaic).
• Maximum value (archaic).
• Maximum value (archaic).
• Minimum value (archaic).
• Minimum value (archaic).
• Remainder (archaic).
• Boolean AND.
• Round to nearest whole number.
• (Reserved for future use.)
• Arc sine.
• (Reserved for future use.)
• Arc tangent.
• Arc tangent.
• Bessel function.
• Bessel function.
• Bessel function.
• Bessel function.
• Bessel function.
• Bessel function.
• Number of bits in argument's type.
• Test bit.
• Absolute value (archaic).
• Cosine (archaic).
• (Reserved for future use.)
• Exponential (archaic).
• Character from code.
• Change directory.
• Change file modes.
• Natural logarithm (archaic).
• Construct COMPLEX(KIND=1) value.
• Build complex value from real and imaginary parts.
• Complex conjugate.
• Cosine.
• Hyperbolic cosine.
• (Reserved for future use.)
• Get current CPU time.
• (Reserved for future use.)
• Sine (archaic).
• Square root (archaic).
• Convert time to Day Mon dd hh:mm:ss yyyy.
• Convert time to Day Mon dd hh:mm:ss yyyy.
• Absolute value (archaic).
• Arc cosine (archaic).
• Arc sine (archaic).
• Arc tangent (archaic).
• Arc tangent (archaic).
• (Reserved for future use.)
• Bessel function (archaic).
• Bessel function (archaic).
• Bessel function (archaic).
• Bessel function (archaic).
• Bessel function (archaic).
• Bessel function (archaic).
• Convert to double precision.
• Cosine (archaic).
• Hyperbolic cosine (archaic).
• Difference magnitude (archaic).
• Error function (archaic).
• Complementary error function (archaic).
• Exponential (archaic).
• (Reserved for future use.)
• Difference magnitude (non-negative subtract).
• Truncate to whole number (archaic).
• Natural logarithm (archaic).
• Natural logarithm (archaic).
• Maximum value (archaic).
• Minimum value (archaic).
• Remainder (archaic).
• Round to nearest whole number (archaic).
• (Reserved for future use.)
• Double-precision product.
• Apply sign to magnitude (archaic).
• Sine (archaic).
• Hyperbolic sine (archaic).
• Square root (archaic).
• Tangent (archaic).
• Hyperbolic tangent (archaic).
• Get elapsed time since last time.
• (Reserved for future use.)
• (Reserved for future use.)
• Error function.
• Complementary error function.
• Get elapsed time for process.
• Get elapsed time for process.
• Terminate the program.
• Exponential.
• (Reserved for future use.)
• Get current time as Day Mon dd hh:mm:ss yyyy.
• Get current time as Day Mon dd hh:mm:ss yyyy.
• Read a character from unit 5 stream-wise.
• Read a character stream-wise.
• Conversion (archaic).
• (Reserved for future use.)
• Flush buffered output.
• Get file descriptor from Fortran unit number.
• Write a character to unit 6 stream-wise.
• Write a character stream-wise.
• (Reserved for future use.)
• Position file (low-level).
• Get file information.
• Get file information.
• Get file position (low-level).
• Get file position (low-level).
• Get error message for last error.
• Obtain command-line argument.
• Get current working directory.
• Get current working directory.
• Get environment variable.
• Get process group id.
• Get login name.
• Get process id.
• Get process user id.
• Convert time to GMT time info.
• Get host name.
• Get host name.
• (Reserved for future use.)
• Absolute value (archaic).
• ASCII code for character.
• Boolean AND.
• Obtain count of command-line arguments.
• Clear a bit.
• Extract a bit subfield of a variable.
• Set a bit.
• Code for character.
• Get local time info.
• Difference magnitude (archaic).
• Convert to INTEGER value truncated to whole number (archaic).
• Convert to INTEGER value rounded to nearest whole number (archaic).
• Boolean XOR.
• Get error number for last error.
• Conversion (archaic).
• Extract imaginary part of complex.
• Extract imaginary part of complex.
• Locate a CHARACTER substring.
• Convert to INTEGER value truncated to whole number.
• Convert to INTEGER(KIND=6) value truncated to whole number.
• Convert to INTEGER(KIND=2) value truncated to whole number.
• Boolean OR.
• Random number.
• Is unit connected to a terminal?
• Logical bit shift.
• Circular bit shift.
• Apply sign to magnitude (archaic).
• Get local time of day.
• Signal a process.
• (Reserved for future use.)
• (Reserved for future use.)
• Length of character entity.
• Get last non-blank character in string.
• Lexically greater than or equal.
• Lexically greater than.
• Make hard link in file system.
• Lexically less than or equal.
• Lexically less than.
• Get last non-blank character in string.
• Address of entity in core.
• Natural logarithm.
• Natural logarithm.
• (Reserved for future use.)
• Conversion to INTEGER(KIND=1) (archaic).
• Left-shift bits.
• Get file information.
• Get file information.
• Convert time to local time info.
• (Reserved for future use.)
• Maximum value.
• Maximum value (archaic).
• Maximum value (archaic).
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Get number of clock ticks for process.
• Get number of clock ticks for process.
• (Reserved for future use.)
• Minimum value.
• Minimum value (archaic).
• Minimum value (archaic).
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Remainder.
• (Reserved for future use.)
• Moving a bit field.
• (Reserved for future use.)
• Convert to INTEGER value rounded to nearest whole number.
• Boolean NOT.
• Boolean OR.
• (Reserved for future use.)
• Print error message for last error.
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Random number.
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Convert value to type REAL(KIND=1).
• Extract real part of complex.
• Rename file.
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Right-shift bits.
• (Reserved for future use.)
• (Reserved for future use.)
• Get CPU time for process in seconds.
• Get CPU time for process in seconds.
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Convert to INTEGER(KIND=6) value truncated to whole number.
• Apply sign to magnitude.
• Muck with signal handling.
• Sine.
• Hyperbolic sine.
• Sleep for a specified time.
• Convert (archaic).
• (Reserved for future use.)
• (Reserved for future use.)
• Square root.
• Random seed.
• Get file information.
• Get file information.
• (Reserved for future use.)
• Make symbolic link in file system.
• Invoke shell (system) command.
• Get current system clock value.
• Tangent.
• Hyperbolic tangent.
• Get current time as time value.
• Get current time as time value.
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• (Reserved for future use.)
• Get name of terminal device for unit.
• Get name of terminal device for unit.
• (Reserved for future use.)
• Set file creation permissions mask.
• Unlink file.
• (Reserved for future use.)
• (Reserved for future use.)
• Boolean XOR.
• Absolute value (archaic).
• Cosine (archaic).
• Exponential (archaic).
• Natural logarithm (archaic).
• Sine (archaic).
• Square root (archaic).

Abort Intrinsic

CALL Abort()

Intrinsic groups: unix. Description:

Prints a message and potentially causes a core dump via abort(3).

Abs Intrinsic

Abs(A)

Abs: INTEGER or REAL function. The exact type depends on that of argument A---if A is COMPLEX, this function's type is REAL with the same KIND= value as the type of A. Otherwise, this function's type is the same as that of A. A: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the absolute value of A.

If A is type COMPLEX, the absolute value is computed as:

SQRT(REALPART(A)**2, IMAGPART(A)**2)

Otherwise, it is computed by negating the A if it is negative, or returning A.

See Sign Intrinsic, for how to explicitly compute the positive or negative form of the absolute value of an expression.

Access Intrinsic

Access(Name, Mode)

Access: INTEGER(KIND=1) function. Name: CHARACTER; scalar; INTENT(IN). Mode: CHARACTER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Checks file Name for accessibility in the mode specified by Mode and returns 0 if the file is accessible in that mode, otherwise an error code if the file is inaccessible or Mode is invalid. See access(2). A null character (CHAR(0)) marks the end of the name in Name---otherwise, trailing blanks in Name are ignored. Mode may be a concatenation of any of the following characters:

r


Read permission

w


Write permission

x


Execute permission

SPC


Existence

AChar Intrinsic

AChar(I)

AChar: CHARACTER*1 function. I: INTEGER; scalar; INTENT(IN). Intrinsic groups: f2c, f90. Description:

Returns the ASCII character corresponding to the code specified by I.

See IAChar Intrinsic, for the inverse of this function.

See Char Intrinsic, for the function corresponding to the system's native character set.

ACos Intrinsic

ACos(X)

ACos: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the arc-cosine (inverse cosine) of X in radians.

See Cos Intrinsic, for the inverse of this function.

AdjustL Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL AdjustL to use this name for an external procedure.

AdjustR Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL AdjustR to use this name for an external procedure.

AImag Intrinsic

AImag(Z)

AImag: REAL function. This intrinsic is valid when argument Z is COMPLEX(KIND=1). When Z is any other COMPLEX type, this intrinsic is valid only when used as the argument to REAL(), as explained below. Z: COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the (possibly converted) imaginary part of Z.

Use of AIMAG() with an argument of a type other than COMPLEX(KIND=1) is restricted to the following case:

REAL(AIMAG(Z))

This expression converts the imaginary part of Z to REAL(KIND=1).

See REAL() and AIMAG() of Complex, for more information.

AInt Intrinsic

AInt(A)

AInt: REAL function, the KIND= value of the type being that of argument A. A: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns A with the fractional portion of its magnitude truncated and its sign preserved. (Also called ``truncation towards zero''.)

See ANInt Intrinsic, for how to round to nearest whole number.

See Int Intrinsic, for how to truncate and then convert number to INTEGER.

Alarm Intrinsic

CALL Alarm(Seconds, Handler, Status)

Seconds: INTEGER; scalar; INTENT(IN). Handler: Signal handler (INTEGER FUNCTION or SUBROUTINE) or dummy/global INTEGER(KIND=1) scalar. Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Causes external subroutine Handler to be executed after a delay of Seconds seconds by using alarm(1) to set up a signal and signal(2) to catch it. If Status is supplied, it will be returned with the the number of seconds remaining until any previously scheduled alarm was due to be delivered, or zero if there was no previously scheduled alarm. See Signal Intrinsic (subroutine).

All Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL All to use this name for an external procedure.

Allocated Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Allocated to use this name for an external procedure.

ALog Intrinsic

ALog(X)

ALog: REAL(KIND=1) function. X: REAL(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of LOG() that is specific to one type for X. See Log Intrinsic.

ALog10 Intrinsic

ALog10(X)

ALog10: REAL(KIND=1) function. X: REAL(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of LOG10() that is specific to one type for X. See Log10 Intrinsic.

AMax0 Intrinsic

AMax0(A-1, A-2, ···, A-n)

AMax0: REAL(KIND=1) function. A: INTEGER(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MAX() that is specific to one type for A and a different return type. See Max Intrinsic.

AMax1 Intrinsic

AMax1(A-1, A-2, ···, A-n)

AMax1: REAL(KIND=1) function. A: REAL(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MAX() that is specific to one type for A. See Max Intrinsic.

AMin0 Intrinsic

AMin0(A-1, A-2, ···, A-n)

AMin0: REAL(KIND=1) function. A: INTEGER(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MIN() that is specific to one type for A and a different return type. See Min Intrinsic.

AMin1 Intrinsic

AMin1(A-1, A-2, ···, A-n)

AMin1: REAL(KIND=1) function. A: REAL(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MIN() that is specific to one type for A. See Min Intrinsic.

AMod Intrinsic

AMod(A, P)

AMod: REAL(KIND=1) function. A: REAL(KIND=1); scalar; INTENT(IN). P: REAL(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MOD() that is specific to one type for A. See Mod Intrinsic.

And Intrinsic

And(I, J)

And: INTEGER or LOGICAL function, the exact type being the result of cross-promoting the types of all the arguments. I: INTEGER or LOGICAL; scalar; INTENT(IN). J: INTEGER or LOGICAL; scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Returns value resulting from boolean AND of pair of bits in each of I and J.

ANInt Intrinsic

ANInt(A)

ANInt: REAL function, the KIND= value of the type being that of argument A. A: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns A with the fractional portion of its magnitude eliminated by rounding to the nearest whole number and with its sign preserved.

A fractional portion exactly equal to .5 is rounded to the whole number that is larger in magnitude. (Also called ``Fortran round''.)

See AInt Intrinsic, for how to truncate to whole number.

See NInt Intrinsic, for how to round and then convert number to INTEGER.

Any Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Any to use this name for an external procedure.

ASin Intrinsic

ASin(X)

ASin: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the arc-sine (inverse sine) of X in radians.

See Sin Intrinsic, for the inverse of this function.

Associated Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Associated to use this name for an external procedure.

ATan Intrinsic

ATan(X)

ATan: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the arc-tangent (inverse tangent) of X in radians.

See Tan Intrinsic, for the inverse of this function.

ATan2 Intrinsic

ATan2(Y, X)

ATan2: REAL function, the exact type being the result of cross-promoting the types of all the arguments. Y: REAL; scalar; INTENT(IN). X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the arc-tangent (inverse tangent) of the complex number (Y, X) in radians.

See Tan Intrinsic, for the inverse of this function.

BesJ0 Intrinsic

BesJ0(X)

BesJ0: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Calculates the Bessel function of the first kind of order 0 of X. See bessel(3m), on whose implementation the function depends.

BesJ1 Intrinsic

BesJ1(X)

BesJ1: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Calculates the Bessel function of the first kind of order 1 of X. See bessel(3m), on whose implementation the function depends.

BesJN Intrinsic

BesJN(N, X)

BesJN: REAL function, the KIND= value of the type being that of argument X. N: INTEGER; scalar; INTENT(IN). X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Calculates the Bessel function of the first kind of order N of X. See bessel(3m), on whose implementation the function depends.

BesY0 Intrinsic

BesY0(X)

BesY0: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Calculates the Bessel function of the second kind of order 0 of X. See bessel(3m), on whose implementation the function depends.

BesY1 Intrinsic

BesY1(X)

BesY1: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Calculates the Bessel function of the second kind of order 1 of X. See bessel(3m), on whose implementation the function depends.

BesYN Intrinsic

BesYN(N, X)

BesYN: REAL function, the KIND= value of the type being that of argument X. N: INTEGER; scalar; INTENT(IN). X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Calculates the Bessel function of the second kind of order N of X. See bessel(3m), on whose implementation the function depends.

Bit_Size Intrinsic

Bit_Size(I)

Bit_Size: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar. Intrinsic groups: f90. Description:

Returns the number of bits (integer precision plus sign bit) represented by the type for I.

See BTest Intrinsic, for how to test the value of a bit in a variable or array.

See IBSet Intrinsic, for how to set a bit in a variable to 1.

See IBClr Intrinsic, for how to set a bit in a variable to 0.

BTest Intrinsic

BTest(I, Pos)

BTest: LOGICAL(KIND=1) function. I: INTEGER; scalar; INTENT(IN). Pos: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns .TRUE. if bit Pos in I is 1, .FALSE. otherwise.

(Bit 0 is the low-order (rightmost) bit, adding the value 2**0, or 1, to the number if set to 1; bit 1 is the next-higher-order bit, adding 2**1, or 2; bit 2 adds 2**2, or 4; and so on.)

See Bit_Size Intrinsic, for how to obtain the number of bits in a type. The leftmost bit of I is BIT_SIZE(I-1).

CAbs Intrinsic

CAbs(A)

CAbs: REAL(KIND=1) function. A: COMPLEX(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ABS() that is specific to one type for A. See Abs Intrinsic.

CCos Intrinsic

CCos(X)

CCos: COMPLEX(KIND=1) function. X: COMPLEX(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of COS() that is specific to one type for X. See Cos Intrinsic.

Ceiling Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Ceiling to use this name for an external procedure.

CExp Intrinsic

CExp(X)

CExp: COMPLEX(KIND=1) function. X: COMPLEX(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of EXP() that is specific to one type for X. See Exp Intrinsic.

Char Intrinsic

Char(I)

Char: CHARACTER*1 function. I: INTEGER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the character corresponding to the code specified by I, using the system's native character set.

Because the system's native character set is used, the correspondence between character and their codes is not necessarily the same between GNU Fortran implementations.

Note that no intrinsic exists to convert a numerical value to a printable character string. For example, there is no intrinsic that, given an INTEGER or REAL argument with the value 154, returns the CHARACTER result '154'.

Instead, you can use internal-file I/O to do this kind of conversion. For example:

INTEGER VALUE
CHARACTER*10 STRING
VALUE = 154
WRITE (STRING, '(I10)'), VALUE
PRINT *, STRING
END

The above program, when run, prints:

        154

See IChar Intrinsic, for the inverse of the CHAR function.

See AChar Intrinsic, for the function corresponding to the ASCII character set.

ChDir Intrinsic (subroutine)

CALL ChDir(Dir, Status)

Dir: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Sets the current working directory to be Dir. If the Status argument is supplied, it contains 0 on success or a non-zero error code otherwise upon return. See chdir(3).

Caution: Using this routine during I/O to a unit connected with a non-absolute file name can cause subsequent I/O on such a unit to fail because the I/O library may reopen files by name.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See ChDir Intrinsic (function).

ChMod Intrinsic (subroutine)

CALL ChMod(Name, Mode, Status)

Name: CHARACTER; scalar; INTENT(IN). Mode: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Changes the access mode of file Name according to the specification Mode, which is given in the format of chmod(1). A null character (CHAR(0)) marks the end of the name in Name---otherwise, trailing blanks in Name are ignored. Currently, Name must not contain the single quote character.

If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return.

Note that this currently works by actually invoking /bin/chmod (or the chmod found when the library was configured) and so may fail in some circumstances and will, anyway, be slow.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See ChMod Intrinsic (function).

CLog Intrinsic

CLog(X)

CLog: COMPLEX(KIND=1) function. X: COMPLEX(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of LOG() that is specific to one type for X. See Log Intrinsic.

Cmplx Intrinsic

Cmplx(X, Y)

Cmplx: COMPLEX(KIND=1) function. X: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Y: INTEGER or REAL; OPTIONAL (must be omitted if X is COMPLEX); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

If X is not type COMPLEX, constructs a value of type COMPLEX(KIND=1) from the real and imaginary values specified by X and Y, respectively. If Y is omitted, 0. is assumed.

If X is type COMPLEX, converts it to type COMPLEX(KIND=1).

See Complex Intrinsic, for information on easily constructing a COMPLEX value of arbitrary precision from REAL arguments.

Complex Intrinsic

Complex(Real, Imag)

Complex: COMPLEX function, the exact type being the result of cross-promoting the types of all the arguments. Real: INTEGER or REAL; scalar; INTENT(IN). Imag: INTEGER or REAL; scalar; INTENT(IN). Intrinsic groups: gnu. Description:

Returns a COMPLEX value that has Real and Imag as its real and imaginary parts, respectively.

If Real and Imag are the same type, and that type is not INTEGER, no data conversion is performed, and the type of the resulting value has the same kind value as the types of Real and Imag.

If Real and Imag are not the same type, the usual type-promotion rules are applied to both, converting either or both to the appropriate REAL type. The type of the resulting value has the same kind value as the type to which both Real and Imag were converted, in this case.

If Real and Imag are both INTEGER, they are both converted to REAL(KIND=1), and the result of the COMPLEX() invocation is type COMPLEX(KIND=1).

Note: The way to do this in standard Fortran 90 is too hairy to describe here, but it is important to note that CMPLX(D1,D2) returns a COMPLEX(KIND=1) result even if D1 and D2 are type REAL(KIND=2). Hence the availability of COMPLEX() in GNU Fortran.

Conjg Intrinsic

Conjg(Z)

Conjg: COMPLEX function, the KIND= value of the type being that of argument Z. Z: COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the complex conjugate:

COMPLEX(REALPART(Z), -IMAGPART(Z))

Cos Intrinsic

Cos(X)

Cos: REAL or COMPLEX function, the exact type being that of argument X. X: REAL or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the cosine of X, an angle measured in radians.

See ACos Intrinsic, for the inverse of this function.

CosH Intrinsic

CosH(X)

CosH: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the hyperbolic cosine of X.

Count Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Count to use this name for an external procedure.

CPU_Time Intrinsic

CALL CPU_Time(Seconds)

Seconds: REAL; scalar; INTENT(OUT). Intrinsic groups: f90. Description:

Returns in Seconds the current value of the system time. This implementation of the Fortran 95 intrinsic is just an alias for second See Second Intrinsic (subroutine).

CShift Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL CShift to use this name for an external procedure.

CSin Intrinsic

CSin(X)

CSin: COMPLEX(KIND=1) function. X: COMPLEX(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SIN() that is specific to one type for X. See Sin Intrinsic.

CSqRt Intrinsic

CSqRt(X)

CSqRt: COMPLEX(KIND=1) function. X: COMPLEX(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SQRT() that is specific to one type for X. See SqRt Intrinsic.

CTime Intrinsic (subroutine)

CALL CTime(Result, STime)

Result: CHARACTER; scalar; INTENT(OUT). STime: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Converts STime, a system time value, such as returned by TIME8(), to a string of the form Sat Aug 19 18:13:14 1995, and returns that string in Result.

See Time8 Intrinsic.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See CTime Intrinsic (function).

CTime Intrinsic (function)

CTime(STime)

CTime: CHARACTER*(*) function. STime: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Converts STime, a system time value, such as returned by TIME8(), to a string of the form Sat Aug 19 18:13:14 1995, and returns that string as the function value.

See Time8 Intrinsic.

For information on other intrinsics with the same name: See CTime Intrinsic (subroutine).

DAbs Intrinsic

DAbs(A)

DAbs: REAL(KIND=2) function. A: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ABS() that is specific to one type for A. See Abs Intrinsic.

DACos Intrinsic

DACos(X)

DACos: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ACOS() that is specific to one type for X. See ACos Intrinsic.

DASin Intrinsic

DASin(X)

DASin: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ASIN() that is specific to one type for X. See ASin Intrinsic.

DATan Intrinsic

DATan(X)

DATan: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ATAN() that is specific to one type for X. See ATan Intrinsic.

DATan2 Intrinsic

DATan2(Y, X)

DATan2: REAL(KIND=2) function. Y: REAL(KIND=2); scalar; INTENT(IN). X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ATAN2() that is specific to one type for Y and X. See ATan2 Intrinsic.

Date_and_Time Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Date_and_Time to use this name for an external procedure.

DbesJ0 Intrinsic

DbesJ0(X)

DbesJ0: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of BESJ0() that is specific to one type for X. See BesJ0 Intrinsic.

DbesJ1 Intrinsic

DbesJ1(X)

DbesJ1: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of BESJ1() that is specific to one type for X. See BesJ1 Intrinsic.

DbesJN Intrinsic

DbesJN(N, X)

DbesJN: REAL(KIND=2) function. N: INTEGER; scalar; INTENT(IN). X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of BESJN() that is specific to one type for X. See BesJN Intrinsic.

DbesY0 Intrinsic

DbesY0(X)

DbesY0: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of BESY0() that is specific to one type for X. See BesY0 Intrinsic.

DbesY1 Intrinsic

DbesY1(X)

DbesY1: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of BESY1() that is specific to one type for X. See BesY1 Intrinsic.

DbesYN Intrinsic

DbesYN(N, X)

DbesYN: REAL(KIND=2) function. N: INTEGER; scalar; INTENT(IN). X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of BESYN() that is specific to one type for X. See BesYN Intrinsic.

Dble Intrinsic

Dble(A)

Dble: REAL(KIND=2) function. A: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns A converted to double precision (REAL(KIND=2)). If A is COMPLEX, the real part of A is used for the conversion and the imaginary part disregarded.

See Sngl Intrinsic, for the function that converts to single precision.

See Int Intrinsic, for the function that converts to INTEGER.

See Complex Intrinsic, for the function that converts to COMPLEX.

DCos Intrinsic

DCos(X)

DCos: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of COS() that is specific to one type for X. See Cos Intrinsic.

DCosH Intrinsic

DCosH(X)

DCosH: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of COSH() that is specific to one type for X. See CosH Intrinsic.

DDiM Intrinsic

DDiM(X, Y)

DDiM: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Y: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of DIM() that is specific to one type for X and Y. See DiM Intrinsic.

DErF Intrinsic

DErF(X)

DErF: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of ERF() that is specific to one type for X. See ErF Intrinsic.

DErFC Intrinsic

DErFC(X)

DErFC: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of ERFC() that is specific to one type for X. See ErFC Intrinsic.

DExp Intrinsic

DExp(X)

DExp: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of EXP() that is specific to one type for X. See Exp Intrinsic.

Digits Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Digits to use this name for an external procedure.

DiM Intrinsic

DiM(X, Y)

DiM: INTEGER or REAL function, the exact type being the result of cross-promoting the types of all the arguments. X: INTEGER or REAL; scalar; INTENT(IN). Y: INTEGER or REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns X-Y if X is greater than Y; otherwise returns zero.

DInt Intrinsic

DInt(A)

DInt: REAL(KIND=2) function. A: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of AINT() that is specific to one type for A. See AInt Intrinsic.

DLog Intrinsic

DLog(X)

DLog: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of LOG() that is specific to one type for X. See Log Intrinsic.

DLog10 Intrinsic

DLog10(X)

DLog10: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of LOG10() that is specific to one type for X. See Log10 Intrinsic.

DMax1 Intrinsic

DMax1(A-1, A-2, ···, A-n)

DMax1: REAL(KIND=2) function. A: REAL(KIND=2); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MAX() that is specific to one type for A. See Max Intrinsic.

DMin1 Intrinsic

DMin1(A-1, A-2, ···, A-n)

DMin1: REAL(KIND=2) function. A: REAL(KIND=2); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MIN() that is specific to one type for A. See Min Intrinsic.

DMod Intrinsic

DMod(A, P)

DMod: REAL(KIND=2) function. A: REAL(KIND=2); scalar; INTENT(IN). P: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MOD() that is specific to one type for A. See Mod Intrinsic.

DNInt Intrinsic

DNInt(A)

DNInt: REAL(KIND=2) function. A: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ANINT() that is specific to one type for A. See ANInt Intrinsic.

Dot_Product Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Dot_Product to use this name for an external procedure.

DProd Intrinsic

DProd(X, Y)

DProd: REAL(KIND=2) function. X: REAL(KIND=1); scalar; INTENT(IN). Y: REAL(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns DBLE(X)*DBLE(Y).

DSign Intrinsic

DSign(A, B)

DSign: REAL(KIND=2) function. A: REAL(KIND=2); scalar; INTENT(IN). B: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SIGN() that is specific to one type for A and B. See Sign Intrinsic.

DSin Intrinsic

DSin(X)

DSin: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SIN() that is specific to one type for X. See Sin Intrinsic.

DSinH Intrinsic

DSinH(X)

DSinH: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SINH() that is specific to one type for X. See SinH Intrinsic.

DSqRt Intrinsic

DSqRt(X)

DSqRt: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SQRT() that is specific to one type for X. See SqRt Intrinsic.

DTan Intrinsic

DTan(X)

DTan: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of TAN() that is specific to one type for X. See Tan Intrinsic.

DTanH Intrinsic

DTanH(X)

DTanH: REAL(KIND=2) function. X: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of TANH() that is specific to one type for X. See TanH Intrinsic.

Dtime Intrinsic (subroutine)

CALL Dtime(Result, TArray)

Result: REAL(KIND=1); scalar; INTENT(OUT). TArray: REAL(KIND=1); DIMENSION(2); INTENT(OUT). Intrinsic groups: unix. Description:

Initially, return the number of seconds of runtime since the start of the process's execution in Result, and the user and system components of this in TArray(1) and TArray(2) respectively. The value of Result is equal to TArray(1) + TArray(2).

Subsequent invocations of DTIME() set values based on accumulations since the previous invocation.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See Dtime Intrinsic (function).

EOShift Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL EOShift to use this name for an external procedure.

Epsilon Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Epsilon to use this name for an external procedure.

ErF Intrinsic

ErF(X)

ErF: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns the error function of X. See erf(3m), which provides the implementation.

ErFC Intrinsic

ErFC(X)

ErFC: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns the complementary error function of X: ERFC(R) = 1 - ERF(R) (except that the result may be more accurate than explicitly evaluating that formulae would give). See erfc(3m), which provides the implementation.

ETime Intrinsic (subroutine)

CALL ETime(Result, TArray)

Result: REAL(KIND=1); scalar; INTENT(OUT). TArray: REAL(KIND=1); DIMENSION(2); INTENT(OUT). Intrinsic groups: unix. Description:

Return the number of seconds of runtime since the start of the process's execution in Result, and the user and system components of this in TArray(1) and TArray(2) respectively. The value of Result is equal to TArray(1) + TArray(2).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See ETime Intrinsic (function).

ETime Intrinsic (function)

ETime(TArray)

ETime: REAL(KIND=1) function. TArray: REAL(KIND=1); DIMENSION(2); INTENT(OUT). Intrinsic groups: unix. Description:

Return the number of seconds of runtime since the start of the process's execution as the function value, and the user and system components of this in TArray(1) and TArray(2) respectively. The functions' value is equal to TArray(1) + TArray(2).

For information on other intrinsics with the same name: See ETime Intrinsic (subroutine).

Exit Intrinsic

CALL Exit(Status)

Status: INTEGER; OPTIONAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Exit the program with status Status after closing open Fortran I/O units and otherwise behaving as exit(2). If Status is omitted the canonical `success' value will be returned to the system.

Exp Intrinsic

Exp(X)

Exp: REAL or COMPLEX function, the exact type being that of argument X. X: REAL or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns e**X, where e is approximately 2.7182818.

See Log Intrinsic, for the inverse of this function.

Exponent Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Exponent to use this name for an external procedure.

Fdate Intrinsic (subroutine)

CALL Fdate(Date)

Date: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Returns the current date (using the same format as CTIME()) in Date.

Equivalent to:

CALL CTIME(Date, TIME8())

See CTime Intrinsic (subroutine).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See Fdate Intrinsic (function).

Fdate Intrinsic (function)

Fdate()

Fdate: CHARACTER*(*) function. Intrinsic groups: unix. Description:

Returns the current date (using the same format as CTIME()).

Equivalent to:

CTIME(TIME8())

See CTime Intrinsic (function).

For information on other intrinsics with the same name: See Fdate Intrinsic (subroutine).

FGet Intrinsic (subroutine)

CALL FGet(C, Status)

C: CHARACTER; scalar; INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Reads a single character into C in stream mode from unit 5 (by-passing normal formatted output) using getc(3). Returns in Status 0 on success, -1 on end-of-file, and the error code from ferror(3) otherwise.

Stream I/O should not be mixed with normal record-oriented (formatted or unformatted) I/O on the same unit; the results are unpredictable.

For information on other intrinsics with the same name: See FGet Intrinsic (function).

FGetC Intrinsic (subroutine)

CALL FGetC(Unit, C, Status)

Unit: INTEGER; scalar; INTENT(IN). C: CHARACTER; scalar; INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Reads a single character into C in stream mode from unit Unit (by-passing normal formatted output) using getc(3). Returns in Status 0 on success, -1 on end-of-file, and the error code from ferror(3) otherwise.

Stream I/O should not be mixed with normal record-oriented (formatted or unformatted) I/O on the same unit; the results are unpredictable.

For information on other intrinsics with the same name: See FGetC Intrinsic (function).

Float Intrinsic

Float(A)

Float: REAL(KIND=1) function. A: INTEGER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of REAL() that is specific to one type for A. See Real Intrinsic.

Floor Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Floor to use this name for an external procedure.

Flush Intrinsic

CALL Flush(Unit)

Unit: INTEGER; OPTIONAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Flushes Fortran unit(s) currently open for output. Without the optional argument, all such units are flushed, otherwise just the unit specified by Unit.

Some non-GNU implementations of Fortran provide this intrinsic as a library procedure that might or might not support the (optional) Unit argument.

FNum Intrinsic

FNum(Unit)

FNum: INTEGER(KIND=1) function. Unit: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns the Unix file descriptor number corresponding to the open Fortran I/O unit Unit. This could be passed to an interface to C I/O routines.

FPut Intrinsic (subroutine)

CALL FPut(C, Status)

C: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Writes the single character C in stream mode to unit 6 (by-passing normal formatted output) using putc(3). Returns in Status 0 on success, the error code from ferror(3) otherwise.

Stream I/O should not be mixed with normal record-oriented (formatted or unformatted) I/O on the same unit; the results are unpredictable.

For information on other intrinsics with the same name: See FPut Intrinsic (function).

FPutC Intrinsic (subroutine)

CALL FPutC(Unit, C, Status)

Unit: INTEGER; scalar; INTENT(IN). C: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Writes the single character Unit in stream mode to unit 6 (by-passing normal formatted output) using putc(3). Returns in C 0 on success, the error code from ferror(3) otherwise.

Stream I/O should not be mixed with normal record-oriented (formatted or unformatted) I/O on the same unit; the results are unpredictable.

For information on other intrinsics with the same name: See FPutC Intrinsic (function).

Fraction Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Fraction to use this name for an external procedure.

FSeek Intrinsic

CALL FSeek(Unit, Offset, Whence, ErrLab)

Unit: INTEGER; scalar; INTENT(IN). Offset: INTEGER; scalar; INTENT(IN). Whence: INTEGER; scalar; INTENT(IN). ErrLab: *label, where label is the label of an executable statement; OPTIONAL. Intrinsic groups: unix. Description:

Attempts to move Fortran unit Unit to the specified Offset: absolute offset if Offset=0; relative to the current offset if Offset=1; relative to the end of the file if Offset=2. It branches to label Whence if Unit is not open or if the call otherwise fails.

FStat Intrinsic (subroutine)

CALL FStat(Unit, SArray, Status)

Unit: INTEGER; scalar; INTENT(IN). SArray: INTEGER(KIND=1); DIMENSION(13); INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Obtains data about the file open on Fortran I/O unit Unit and places them in the array SArray. The values in this array are extracted from the stat structure as returned by fstat(2) q.v., as follows:

1. File mode
2. Inode number
3. ID of device containing directory entry for file
4. Device id (if relevant)
5. Number of links
6. Owner's uid
7. Owner's gid
8. File size (bytes)
9. Last access time
10. Last modification time
11. Last file status change time
12. Preferred I/O block size
13. Number of blocks allocated

Not all these elements are relevant on all systems. If an element is not relevant, it is returned as 0.

If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See FStat Intrinsic (function).

FStat Intrinsic (function)

FStat(Unit, SArray)

FStat: INTEGER(KIND=1) function. Unit: INTEGER; scalar; INTENT(IN). SArray: INTEGER(KIND=1); DIMENSION(13); INTENT(OUT). Intrinsic groups: unix. Description:

Obtains data about the file open on Fortran I/O unit Unit and places them in the array SArray. The values in this array are extracted from the stat structure as returned by fstat(2) q.v., as follows:

1. File mode
2. Inode number
3. ID of device containing directory entry for file
4. Device id (if relevant)
5. Number of links
6. Owner's uid
7. Owner's gid
8. File size (bytes)
9. Last access time
10. Last modification time
11. Last file status change time
12. Preferred I/O block size
13. Number of blocks allocated

Not all these elements are relevant on all systems. If an element is not relevant, it is returned as 0.

Returns 0 on success or a non-zero error code.

For information on other intrinsics with the same name: See FStat Intrinsic (subroutine).

FTell Intrinsic (subroutine)

CALL FTell(Unit, Offset)

Unit: INTEGER; scalar; INTENT(IN). Offset: INTEGER(KIND=1); scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Sets Offset to the current offset of Fortran unit Unit (or to -1 if Unit is not open).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See FTell Intrinsic (function).

FTell Intrinsic (function)

FTell(Unit)

FTell: INTEGER(KIND=1) function. Unit: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns the current offset of Fortran unit Unit (or -1 if Unit is not open).

For information on other intrinsics with the same name: See FTell Intrinsic (subroutine).

GError Intrinsic

CALL GError(Message)

Message: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Returns the system error message corresponding to the last system error (C errno).

GetArg Intrinsic

CALL GetArg(Pos, Value)

Pos: INTEGER; scalar; INTENT(IN). Value: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Sets Value to the Pos-th command-line argument (or to all blanks if there are fewer than Value command-line arguments); CALL GETARG(0, value) sets value to the name of the program (on systems that support this feature).

See IArgC Intrinsic, for information on how to get the number of arguments.

GetCWD Intrinsic (subroutine)

CALL GetCWD(Name, Status)

Name: CHARACTER; scalar; INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Places the current working directory in Name. If the Status argument is supplied, it contains 0 success or a non-zero error code upon return (ENOSYS if the system does not provide getcwd(3) or getwd(3)).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See GetCWD Intrinsic (function).

GetCWD Intrinsic (function)

GetCWD(Name)

GetCWD: INTEGER(KIND=1) function. Name: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Places the current working directory in Name. Returns 0 on success, otherwise a non-zero error code (ENOSYS if the system does not provide getcwd(3) or getwd(3)).

For information on other intrinsics with the same name: See GetCWD Intrinsic (subroutine).

GetEnv Intrinsic

CALL GetEnv(Name, Value)

Name: CHARACTER; scalar; INTENT(IN). Value: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Sets Value to the value of environment variable given by the value of Name ($name in shell terms) or to blanks if $name has not been set. A null character (CHAR(0)) marks the end of the name in Name---otherwise, trailing blanks in Name are ignored.

GetGId Intrinsic

GetGId()

GetGId: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the group id for the current process.

GetLog Intrinsic

CALL GetLog(Login)

Login: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Returns the login name for the process in Login.

Caution: On some systems, the getlogin(3) function, which this intrinsic calls at run time, is either not implemented or returns a null pointer. In the latter case, this intrinsic returns blanks in Login.

GetPId Intrinsic

GetPId()

GetPId: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the process id for the current process.

GetUId Intrinsic

GetUId()

GetUId: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the user id for the current process.

GMTime Intrinsic

CALL GMTime(STime, TArray)

STime: INTEGER(KIND=1); scalar; INTENT(IN). TArray: INTEGER(KIND=1); DIMENSION(9); INTENT(OUT). Intrinsic groups: unix. Description:

Given a system time value STime, fills TArray with values extracted from it appropriate to the GMT time zone using gmtime(3).

The array elements are as follows:

1. Seconds after the minute, range 0--59 or 0--61 to allow for leap seconds
2. Minutes after the hour, range 0--59
3. Hours past midnight, range 0--23
4. Day of month, range 0--31
5. Number of months since January, range 0--12
6. Years since 1900
7. Number of days since Sunday, range 0--6
8. Days since January 1
9. Daylight savings indicator: positive if daylight savings is in effect, zero if not, and negative if the information isn't available.

HostNm Intrinsic (subroutine)

CALL HostNm(Name, Status)

Name: CHARACTER; scalar; INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Fills Name with the system's host name returned by gethostname(2). If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return (ENOSYS if the system does not provide gethostname(2)).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See HostNm Intrinsic (function).

HostNm Intrinsic (function)

HostNm(Name)

HostNm: INTEGER(KIND=1) function. Name: CHARACTER; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Fills Name with the system's host name returned by gethostname(2), returning 0 on success or a non-zero error code (ENOSYS if the system does not provide gethostname(2)).

For information on other intrinsics with the same name: See HostNm Intrinsic (subroutine).

Huge Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Huge to use this name for an external procedure.

IAbs Intrinsic

IAbs(A)

IAbs: INTEGER(KIND=1) function. A: INTEGER(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of ABS() that is specific to one type for A. See Abs Intrinsic.

IAChar Intrinsic

IAChar(C)

IAChar: INTEGER(KIND=1) function. C: CHARACTER; scalar; INTENT(IN). Intrinsic groups: f2c, f90. Description:

Returns the code for the ASCII character in the first character position of C.

See AChar Intrinsic, for the inverse of this function.

See IChar Intrinsic, for the function corresponding to the system's native character set.

IAnd Intrinsic

IAnd(I, J)

IAnd: INTEGER function, the exact type being the result of cross-promoting the types of all the arguments. I: INTEGER; scalar; INTENT(IN). J: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns value resulting from boolean AND of pair of bits in each of I and J.

IArgC Intrinsic

IArgC()

IArgC: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the number of command-line arguments.

This count does not include the specification of the program name itself.

IBClr Intrinsic

IBClr(I, Pos)

IBClr: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Pos: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns the value of I with bit Pos cleared (set to zero). See BTest Intrinsic for information on bit positions.

IBits Intrinsic

IBits(I, Pos, Len)

IBits: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Pos: INTEGER; scalar; INTENT(IN). Len: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Extracts a subfield of length Len from I, starting from bit position Pos and extending left for Len bits. The result is right-justified and the remaining bits are zeroed. The value of Pos+Len must be less than or equal to the value BIT_SIZE(I). See Bit_Size Intrinsic.

IBSet Intrinsic

IBSet(I, Pos)

IBSet: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Pos: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns the value of I with bit Pos set (to one). See BTest Intrinsic for information on bit positions.

IChar Intrinsic

IChar(C)

IChar: INTEGER(KIND=1) function. C: CHARACTER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the code for the character in the first character position of C.

Because the system's native character set is used, the correspondence between character and their codes is not necessarily the same between GNU Fortran implementations.

Note that no intrinsic exists to convert a printable character string to a numerical value. For example, there is no intrinsic that, given the CHARACTER value '154', returns an INTEGER or REAL value with the value 154.

Instead, you can use internal-file I/O to do this kind of conversion. For example:

INTEGER VALUE
CHARACTER*10 STRING
STRING = '154'
READ (STRING, '(I10)'), VALUE
PRINT *, VALUE
END

The above program, when run, prints:

 154

See Char Intrinsic, for the inverse of the ICHAR function.

See IAChar Intrinsic, for the function corresponding to the ASCII character set.

IDate Intrinsic (UNIX)

CALL IDate(TArray)

TArray: INTEGER(KIND=1); DIMENSION(3); INTENT(OUT). Intrinsic groups: unix. Description:

Fills TArray with the numerical values at the current local time of day, month (in the range 1--12), and year in elements 1, 2, and 3, respectively. The year has four significant digits.

For information on other intrinsics with the same name: See IDate Intrinsic (VXT).

IDiM Intrinsic

IDiM(X, Y)

IDiM: INTEGER(KIND=1) function. X: INTEGER(KIND=1); scalar; INTENT(IN). Y: INTEGER(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of DIM() that is specific to one type for X and Y. See DiM Intrinsic.

IDInt Intrinsic

IDInt(A)

IDInt: INTEGER(KIND=1) function. A: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of INT() that is specific to one type for A. See Int Intrinsic.

IDNInt Intrinsic

IDNInt(A)

IDNInt: INTEGER(KIND=1) function. A: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of NINT() that is specific to one type for A. See NInt Intrinsic.

IEOr Intrinsic

IEOr(I, J)

IEOr: INTEGER function, the exact type being the result of cross-promoting the types of all the arguments. I: INTEGER; scalar; INTENT(IN). J: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns value resulting from boolean exclusive-OR of pair of bits in each of I and J.

IErrNo Intrinsic

IErrNo()

IErrNo: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the last system error number (corresponding to the C errno).

IFix Intrinsic

IFix(A)

IFix: INTEGER(KIND=1) function. A: REAL(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of INT() that is specific to one type for A. See Int Intrinsic.

Imag Intrinsic

Imag(Z)

Imag: REAL function, the KIND= value of the type being that of argument Z. Z: COMPLEX; scalar; INTENT(IN). Intrinsic groups: f2c. Description:

The imaginary part of Z is returned, without conversion.

Note: The way to do this in standard Fortran 90 is AIMAG(Z). However, when, for example, Z is DOUBLE COMPLEX, AIMAG(Z) means something different for some compilers that are not true Fortran 90 compilers but offer some extensions standardized by Fortran 90 (such as the DOUBLE COMPLEX type, also known as COMPLEX(KIND=2)).

The advantage of IMAG() is that, while not necessarily more or less portable than AIMAG(), it is more likely to cause a compiler that doesn't support it to produce a diagnostic than generate incorrect code.

See REAL() and AIMAG() of Complex, for more information.

ImagPart Intrinsic

ImagPart(Z)

ImagPart: REAL function, the KIND= value of the type being that of argument Z. Z: COMPLEX; scalar; INTENT(IN). Intrinsic groups: gnu. Description:

The imaginary part of Z is returned, without conversion.

Note: The way to do this in standard Fortran 90 is AIMAG(Z). However, when, for example, Z is DOUBLE COMPLEX, AIMAG(Z) means something different for some compilers that are not true Fortran 90 compilers but offer some extensions standardized by Fortran 90 (such as the DOUBLE COMPLEX type, also known as COMPLEX(KIND=2)).

The advantage of IMAGPART() is that, while not necessarily more or less portable than AIMAG(), it is more likely to cause a compiler that doesn't support it to produce a diagnostic than generate incorrect code.

See REAL() and AIMAG() of Complex, for more information.

Index Intrinsic

Index(String, Substring)

Index: INTEGER(KIND=1) function. String: CHARACTER; scalar; INTENT(IN). Substring: CHARACTER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the position of the start of the first occurrence of string Substring as a substring in String, counting from one. If Substring doesn't occur in String, zero is returned.

Int Intrinsic

Int(A)

Int: INTEGER(KIND=1) function. A: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns A with the fractional portion of its magnitude truncated and its sign preserved, converted to type INTEGER(KIND=1).

If A is type COMPLEX, its real part is truncated and converted, and its imaginary part is disregarded.

See NInt Intrinsic, for how to convert, rounded to nearest whole number.

See AInt Intrinsic, for how to truncate to whole number without converting.

Int2 Intrinsic

Int2(A)

Int2: INTEGER(KIND=6) function. A: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Intrinsic groups: gnu. Description:

Returns A with the fractional portion of its magnitude truncated and its sign preserved, converted to type INTEGER(KIND=6).

If A is type COMPLEX, its real part is truncated and converted, and its imaginary part is disgregarded.

See Int Intrinsic.

The precise meaning of this intrinsic might change in a future version of the GNU Fortran language, as more is learned about how it is used.

Int8 Intrinsic

Int8(A)

Int8: INTEGER(KIND=2) function. A: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Intrinsic groups: gnu. Description:

Returns A with the fractional portion of its magnitude truncated and its sign preserved, converted to type INTEGER(KIND=2).

If A is type COMPLEX, its real part is truncated and converted, and its imaginary part is disgregarded.

See Int Intrinsic.

The precise meaning of this intrinsic might change in a future version of the GNU Fortran language, as more is learned about how it is used.

IOr Intrinsic

IOr(I, J)

IOr: INTEGER function, the exact type being the result of cross-promoting the types of all the arguments. I: INTEGER; scalar; INTENT(IN). J: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns value resulting from boolean OR of pair of bits in each of I and J.

IRand Intrinsic

IRand(Flag)

IRand: INTEGER(KIND=1) function. Flag: INTEGER; OPTIONAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns a uniform quasi-random number up to a system-dependent limit. If Flag is 0, the next number in sequence is returned; if Flag is 1, the generator is restarted by calling the UNIX function srand(0); if Flag has any other value, it is used as a new seed with srand().

See SRand Intrinsic.

Note: As typically implemented (by the routine of the same name in the C library), this random number generator is a very poor one, though the BSD and GNU libraries provide a much better implementation than the `traditional' one. On a different system you almost certainly want to use something better.

IsaTty Intrinsic

IsaTty(Unit)

IsaTty: LOGICAL(KIND=1) function. Unit: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns .TRUE. if and only if the Fortran I/O unit specified by Unit is connected to a terminal device. See isatty(3).

IShft Intrinsic

IShft(I, Shift)

IShft: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Shift: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

All bits representing I are shifted Shift places. Shift.GT.0 indicates a left shift, Shift.EQ.0 indicates no shift and Shift.LT.0 indicates a right shift. If the absolute value of the shift count is greater than BIT_SIZE(I), the result is undefined. Bits shifted out from the left end or the right end, as the case may be, are lost. Zeros are shifted in from the opposite end.

See IShftC Intrinsic for the circular-shift equivalent.

IShftC Intrinsic

IShftC(I, Shift, Size)

IShftC: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Shift: INTEGER; scalar; INTENT(IN). Size: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

The rightmost Size bits of the argument I are shifted circularly Shift places, i.e.@ the bits shifted out of one end are shifted into the opposite end. No bits are lost. The unshifted bits of the result are the same as the unshifted bits of I. The absolute value of the argument Shift must be less than or equal to Size. The value of Size must be greater than or equal to one and less than or equal to BIT_SIZE(I).

See IShft Intrinsic for the logical shift equivalent.

ISign Intrinsic

ISign(A, B)

ISign: INTEGER(KIND=1) function. A: INTEGER(KIND=1); scalar; INTENT(IN). B: INTEGER(KIND=1); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of SIGN() that is specific to one type for A and B. See Sign Intrinsic.

ITime Intrinsic

CALL ITime(TArray)

TArray: INTEGER(KIND=1); DIMENSION(3); INTENT(OUT). Intrinsic groups: unix. Description:

Returns the current local time hour, minutes, and seconds in elements 1, 2, and 3 of TArray, respectively.

Kill Intrinsic (subroutine)

CALL Kill(Pid, Signal, Status)

Pid: INTEGER; scalar; INTENT(IN). Signal: INTEGER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Sends the signal specified by Signal to the process Pid. If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return. See kill(2).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See Kill Intrinsic (function).

Kind Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Kind to use this name for an external procedure.

LBound Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL LBound to use this name for an external procedure.

Len Intrinsic

Len(String)

Len: INTEGER(KIND=1) function. String: CHARACTER; scalar. Intrinsic groups: (standard FORTRAN 77). Description:

Returns the length of String.

If String is an array, the length of an element of String is returned.

Note that String need not be defined when this intrinsic is invoked, since only the length, not the content, of String is needed.

See Bit_Size Intrinsic, for the function that determines the size of its argument in bits.

Len_Trim Intrinsic

Len_Trim(String)

Len_Trim: INTEGER(KIND=1) function. String: CHARACTER; scalar; INTENT(IN). Intrinsic groups: f90. Description:

Returns the index of the last non-blank character in String. LNBLNK and LEN_TRIM are equivalent.

LGe Intrinsic

LGe(String_A, String_B)

LGe: LOGICAL(KIND=1) function. String_A: CHARACTER; scalar; INTENT(IN). String_B: CHARACTER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns .TRUE. if String_A.GE.String_B, .FALSE. otherwise. String_A and String_B are interpreted as containing ASCII character codes. If either value contains a character not in the ASCII character set, the result is processor dependent.

If the String_A and String_B are not the same length, the shorter is compared as if spaces were appended to it to form a value that has the same length as the longer.

The lexical comparison intrinsics LGe, LGt, LLe, and LLt differ from the corresponding intrinsic operators .GE., .GT., .LE., .LT.. Because the ASCII collating sequence is assumed, the following expressions always return .TRUE.:

LGE ('0', ' ')
LGE ('A', '0')
LGE ('a', 'A')

The following related expressions do not always return .TRUE., as they are not necessarily evaluated assuming the arguments use ASCII encoding:

'0' .GE. ' '
'A' .GE. '0'
'a' .GE. 'A'

The same difference exists between LGt and .GT.; between LLe and .LE.; and between LLt and .LT..

LGt Intrinsic

LGt(String_A, String_B)

LGt: LOGICAL(KIND=1) function. String_A: CHARACTER; scalar; INTENT(IN). String_B: CHARACTER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns .TRUE. if String_A.GT.String_B, .FALSE. otherwise. String_A and String_B are interpreted as containing ASCII character codes. If either value contains a character not in the ASCII character set, the result is processor dependent.

If the String_A and String_B are not the same length, the shorter is compared as if spaces were appended to it to form a value that has the same length as the longer.

See LGe Intrinsic, for information on the distinction between the LGT intrinsic and the .GT. operator.

Link Intrinsic (subroutine)

CALL Link(Path1, Path2, Status)

Path1: CHARACTER; scalar; INTENT(IN). Path2: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Makes a (hard) link from file Path1 to Path2. A null character (CHAR(0)) marks the end of the names in Path1 and Path2---otherwise, trailing blanks in Path1 and Path2 are ignored. If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return. See link(2).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See Link Intrinsic (function).

LLe Intrinsic

LLe(String_A, String_B)

LLe: LOGICAL(KIND=1) function. String_A: CHARACTER; scalar; INTENT(IN). String_B: CHARACTER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns .TRUE. if String_A.LE.String_B, .FALSE. otherwise. String_A and String_B are interpreted as containing ASCII character codes. If either value contains a character not in the ASCII character set, the result is processor dependent.

If the String_A and String_B are not the same length, the shorter is compared as if spaces were appended to it to form a value that has the same length as the longer.

See LGe Intrinsic, for information on the distinction between the LLE intrinsic and the .LE. operator.

LLt Intrinsic

LLt(String_A, String_B)

LLt: LOGICAL(KIND=1) function. String_A: CHARACTER; scalar; INTENT(IN). String_B: CHARACTER; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns .TRUE. if String_A.LT.String_B, .FALSE. otherwise. String_A and String_B are interpreted as containing ASCII character codes. If either value contains a character not in the ASCII character set, the result is processor dependent.

If the String_A and String_B are not the same length, the shorter is compared as if spaces were appended to it to form a value that has the same length as the longer.

See LGe Intrinsic, for information on the distinction between the LLT intrinsic and the .LT. operator.

LnBlnk Intrinsic

LnBlnk(String)

LnBlnk: INTEGER(KIND=1) function. String: CHARACTER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns the index of the last non-blank character in String. LNBLNK and LEN_TRIM are equivalent.

Loc Intrinsic

Loc(Entity)

Loc: INTEGER(KIND=7) function. Entity: Any type; cannot be a constant or expression. Intrinsic groups: unix. Description:

The LOC() intrinsic works the same way as the %LOC() construct. See The %LOC() Construct, for more information.

Log Intrinsic

Log(X)

Log: REAL or COMPLEX function, the exact type being that of argument X. X: REAL or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the natural logarithm of X, which must be greater than zero or, if type COMPLEX, must not be zero.

See Exp Intrinsic, for the inverse of this function.

See Log10 Intrinsic, for the base-10 logarithm function.

Log10 Intrinsic

Log10(X)

Log10: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the natural logarithm of X, which must be greater than zero or, if type COMPLEX, must not be zero.

The inverse of this function is 10. ** LOG10(X).

See Log Intrinsic, for the natural logarithm function.

Logical Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Logical to use this name for an external procedure.

Long Intrinsic

Long(A)

Long: INTEGER(KIND=1) function. A: INTEGER(KIND=6); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Archaic form of INT() that is specific to one type for A. See Int Intrinsic.

The precise meaning of this intrinsic might change in a future version of the GNU Fortran language, as more is learned about how it is used.

LShift Intrinsic

LShift(I, Shift)

LShift: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Shift: INTEGER; scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Returns I shifted to the left Shift bits.

Although similar to the expression I*(2**Shift), there are important differences. For example, the sign of the result is not necessarily the same as the sign of I.

Currently this intrinsic is defined assuming the underlying representation of I is as a two's-complement integer. It is unclear at this point whether that definition will apply when a different representation is involved.

See LShift Intrinsic, for the inverse of this function.

See IShft Intrinsic, for information on a more widely available left-shifting intrinsic that is also more precisely defined.

LStat Intrinsic (subroutine)

CALL LStat(File, SArray, Status)

File: CHARACTER; scalar; INTENT(IN). SArray: INTEGER(KIND=1); DIMENSION(13); INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Obtains data about the given file File and places them in the array SArray. A null character (CHAR(0)) marks the end of the name in File---otherwise, trailing blanks in File are ignored. If File is a symbolic link it returns data on the link itself, so the routine is available only on systems that support symbolic links. The values in this array are extracted from the stat structure as returned by fstat(2) q.v., as follows:

1. File mode
2. Inode number
3. ID of device containing directory entry for file
4. Device id (if relevant)
5. Number of links
6. Owner's uid
7. Owner's gid
8. File size (bytes)
9. Last access time
10. Last modification time
11. Last file status change time
12. Preferred I/O block size
13. Number of blocks allocated

Not all these elements are relevant on all systems. If an element is not relevant, it is returned as 0.

If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return (ENOSYS if the system does not provide lstat(2)).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See LStat Intrinsic (function).

LStat Intrinsic (function)

LStat(File, SArray)

LStat: INTEGER(KIND=1) function. File: CHARACTER; scalar; INTENT(IN). SArray: INTEGER(KIND=1); DIMENSION(13); INTENT(OUT). Intrinsic groups: unix. Description:

Obtains data about the given file File and places them in the array SArray. A null character (CHAR(0)) marks the end of the name in File---otherwise, trailing blanks in File are ignored. If File is a symbolic link it returns data on the link itself, so the routine is available only on systems that support symbolic links. The values in this array are extracted from the stat structure as returned by fstat(2) q.v., as follows:

1. File mode
2. Inode number
3. ID of device containing directory entry for file
4. Device id (if relevant)
5. Number of links
6. Owner's uid
7. Owner's gid
8. File size (bytes)
9. Last access time
10. Last modification time
11. Last file status change time
12. Preferred I/O block size
13. Number of blocks allocated

Not all these elements are relevant on all systems. If an element is not relevant, it is returned as 0.

Returns 0 on success or a non-zero error code (ENOSYS if the system does not provide lstat(2)).

For information on other intrinsics with the same name: See LStat Intrinsic (subroutine).

LTime Intrinsic

CALL LTime(STime, TArray)

STime: INTEGER(KIND=1); scalar; INTENT(IN). TArray: INTEGER(KIND=1); DIMENSION(9); INTENT(OUT). Intrinsic groups: unix. Description:

Given a system time value STime, fills TArray with values extracted from it appropriate to the GMT time zone using localtime(3).

The array elements are as follows:

1. Seconds after the minute, range 0--59 or 0--61 to allow for leap seconds
2. Minutes after the hour, range 0--59
3. Hours past midnight, range 0--23
4. Day of month, range 0--31
5. Number of months since January, range 0--12
6. Years since 1900
7. Number of days since Sunday, range 0--6
8. Days since January 1
9. Daylight savings indicator: positive if daylight savings is in effect, zero if not, and negative if the information isn't available.

MatMul Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MatMul to use this name for an external procedure.

Max Intrinsic

Max(A-1, A-2, ···, A-n)

Max: INTEGER or REAL function, the exact type being the result of cross-promoting the types of all the arguments. A: INTEGER or REAL; at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the argument with the largest value.

See Min Intrinsic, for the opposite function.

Max0 Intrinsic

Max0(A-1, A-2, ···, A-n)

Max0: INTEGER(KIND=1) function. A: INTEGER(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MAX() that is specific to one type for A. See Max Intrinsic.

Max1 Intrinsic

Max1(A-1, A-2, ···, A-n)

Max1: INTEGER(KIND=1) function. A: REAL(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MAX() that is specific to one type for A and a different return type. See Max Intrinsic.

MaxExponent Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MaxExponent to use this name for an external procedure.

MaxLoc Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MaxLoc to use this name for an external procedure.

MaxVal Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MaxVal to use this name for an external procedure.

MClock Intrinsic

MClock()

MClock: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the number of clock ticks since the start of the process. Supported on systems with clock(3) (q.v.).

This intrinsic is not fully portable, such as to systems with 32-bit INTEGER types but supporting times wider than 32 bits. See MClock8 Intrinsic, for information on a similar intrinsic that might be portable to more GNU Fortran implementations, though to fewer Fortran compilers.

If the system does not support clock(3), -1 is returned.

MClock8 Intrinsic

MClock8()

MClock8: INTEGER(KIND=2) function. Intrinsic groups: unix. Description:

Returns the number of clock ticks since the start of the process. Supported on systems with clock(3) (q.v.).

No Fortran implementations other than GNU Fortran are known to support this intrinsic at the time of this writing. See MClock Intrinsic, for information on a similar intrinsic that might be portable to more Fortran compilers, though to fewer GNU Fortran implementations.

If the system does not support clock(3), -1 is returned.

Merge Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Merge to use this name for an external procedure.

Min Intrinsic

Min(A-1, A-2, ···, A-n)

Min: INTEGER or REAL function, the exact type being the result of cross-promoting the types of all the arguments. A: INTEGER or REAL; at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the argument with the smallest value.

See Max Intrinsic, for the opposite function.

Min0 Intrinsic

Min0(A-1, A-2, ···, A-n)

Min0: INTEGER(KIND=1) function. A: INTEGER(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MIN() that is specific to one type for A. See Min Intrinsic.

Min1 Intrinsic

Min1(A-1, A-2, ···, A-n)

Min1: INTEGER(KIND=1) function. A: REAL(KIND=1); at least two such arguments must be provided; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of MIN() that is specific to one type for A and a different return type. See Min Intrinsic.

MinExponent Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MinExponent to use this name for an external procedure.

MinLoc Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MinLoc to use this name for an external procedure.

MinVal Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL MinVal to use this name for an external procedure.

Mod Intrinsic

Mod(A, P)

Mod: INTEGER or REAL function, the exact type being the result of cross-promoting the types of all the arguments. A: INTEGER or REAL; scalar; INTENT(IN). P: INTEGER or REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns remainder calculated as:

A - (INT(A / P) * P)

P must not be zero.

Modulo Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Modulo to use this name for an external procedure.

MvBits Intrinsic

CALL MvBits(From, FromPos, Len, TO, ToPos)

From: INTEGER; scalar; INTENT(IN). FromPos: INTEGER; scalar; INTENT(IN). Len: INTEGER; scalar; INTENT(IN). TO: INTEGER with same KIND= value as for From; scalar; INTENT(INOUT). ToPos: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Moves Len bits from positions FromPos through FromPos+Len-1 of From to positions ToPos through FromPos+Len-1 of TO. The portion of argument TO not affected by the movement of bits is unchanged. Arguments From and TO are permitted to be the same numeric storage unit. The values of FromPos+Len and ToPos+Len must be less than or equal to BIT_SIZE(From).

Nearest Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Nearest to use this name for an external procedure.

NInt Intrinsic

NInt(A)

NInt: INTEGER(KIND=1) function. A: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns A with the fractional portion of its magnitude eliminated by rounding to the nearest whole number and with its sign preserved, converted to type INTEGER(KIND=1).

If A is type COMPLEX, its real part is rounded and converted.

A fractional portion exactly equal to .5 is rounded to the whole number that is larger in magnitude. (Also called ``Fortran round''.)

See Int Intrinsic, for how to convert, truncate to whole number.

See ANInt Intrinsic, for how to round to nearest whole number without converting.

Not Intrinsic

Not(I)

Not: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Intrinsic groups: mil, f90, vxt. Description:

Returns value resulting from boolean NOT of each bit in I.

Or Intrinsic

Or(I, J)

Or: INTEGER or LOGICAL function, the exact type being the result of cross-promoting the types of all the arguments. I: INTEGER or LOGICAL; scalar; INTENT(IN). J: INTEGER or LOGICAL; scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Returns value resulting from boolean OR of pair of bits in each of I and J.

Pack Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Pack to use this name for an external procedure.

PError Intrinsic

CALL PError(String)

String: CHARACTER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Prints (on the C stderr stream) a newline-terminated error message corresponding to the last system error. This is prefixed by String, a colon and a space. See perror(3).

Precision Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Precision to use this name for an external procedure.

Present Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Present to use this name for an external procedure.

Product Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Product to use this name for an external procedure.

Radix Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Radix to use this name for an external procedure.

Rand Intrinsic

Rand(Flag)

Rand: REAL(KIND=1) function. Flag: INTEGER; OPTIONAL; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns a uniform quasi-random number between 0 and 1. If Flag is 0, the next number in sequence is returned; if Flag is 1, the generator is restarted by calling srand(0); if Flag has any other value, it is used as a new seed with srand.

See SRand Intrinsic.

Note: As typically implemented (by the routine of the same name in the C library), this random number generator is a very poor one, though the BSD and GNU libraries provide a much better implementation than the `traditional' one. On a different system you almost certainly want to use something better.

Random_Number Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Random_Number to use this name for an external procedure.

Random_Seed Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Random_Seed to use this name for an external procedure.

Range Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Range to use this name for an external procedure.

Real Intrinsic

Real(A)

Real: REAL function. The exact type is REAL(KIND=1) when argument A is any type other than COMPLEX, or when it is COMPLEX(KIND=1). When A is any COMPLEX type other than COMPLEX(KIND=1), this intrinsic is valid only when used as the argument to REAL(), as explained below. A: INTEGER, REAL, or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Converts A to REAL(KIND=1).

Use of REAL() with a COMPLEX argument (other than COMPLEX(KIND=1)) is restricted to the following case:

REAL(REAL(A))

This expression converts the real part of A to REAL(KIND=1).

See RealPart Intrinsic, for information on a GNU Fortran intrinsic that extracts the real part of an arbitrary COMPLEX value.

See REAL() and AIMAG() of Complex, for more information.

RealPart Intrinsic

RealPart(Z)

RealPart: REAL function, the KIND= value of the type being that of argument Z. Z: COMPLEX; scalar; INTENT(IN). Intrinsic groups: gnu. Description:

The real part of Z is returned, without conversion.

Note: The way to do this in standard Fortran 90 is REAL(Z). However, when, for example, Z is COMPLEX(KIND=2), REAL(Z) means something different for some compilers that are not true Fortran 90 compilers but offer some extensions standardized by Fortran 90 (such as the DOUBLE COMPLEX type, also known as COMPLEX(KIND=2)).

The advantage of REALPART() is that, while not necessarily more or less portable than REAL(), it is more likely to cause a compiler that doesn't support it to produce a diagnostic than generate incorrect code.

See REAL() and AIMAG() of Complex, for more information.

Rename Intrinsic (subroutine)

CALL Rename(Path1, Path2, Status)

Path1: CHARACTER; scalar; INTENT(IN). Path2: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Renames the file Path1 to Path2. A null character (CHAR(0)) marks the end of the names in Path1 and Path2---otherwise, trailing blanks in Path1 and Path2 are ignored. See rename(2). If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See Rename Intrinsic (function).

Repeat Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Repeat to use this name for an external procedure.

Reshape Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Reshape to use this name for an external procedure.

RRSpacing Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL RRSpacing to use this name for an external procedure.

RShift Intrinsic

RShift(I, Shift)

RShift: INTEGER function, the KIND= value of the type being that of argument I. I: INTEGER; scalar; INTENT(IN). Shift: INTEGER; scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Returns I shifted to the right Shift bits.

Although similar to the expression I/(2**Shift), there are important differences. For example, the sign of the result is undefined.

Currently this intrinsic is defined assuming the underlying representation of I is as a two's-complement integer. It is unclear at this point whether that definition will apply when a different representation is involved.

See RShift Intrinsic, for the inverse of this function.

See IShft Intrinsic, for information on a more widely available right-shifting intrinsic that is also more precisely defined.

Scale Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Scale to use this name for an external procedure.

Scan Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Scan to use this name for an external procedure.

Second Intrinsic (function)

Second()

Second: REAL(KIND=1) function. Intrinsic groups: unix. Description:

Returns the process's runtime in seconds---the same value as the UNIX function etime returns.

For information on other intrinsics with the same name: See Second Intrinsic (subroutine).

Second Intrinsic (subroutine)

CALL Second(Seconds)

Seconds: REAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Returns the process's runtime in seconds in Seconds---the same value as the UNIX function etime returns.

This routine is known from Cray Fortran. See CPU_Time Intrinsic for a standard equivalent.

For information on other intrinsics with the same name: See Second Intrinsic (function).

Selected_Int_Kind Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Selected_Int_Kind to use this name for an external procedure.

Selected_Real_Kind Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Selected_Real_Kind to use this name for an external procedure.

Set_Exponent Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Set_Exponent to use this name for an external procedure.

Shape Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Shape to use this name for an external procedure.

Short Intrinsic

Short(A)

Short: INTEGER(KIND=6) function. A: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns A with the fractional portion of its magnitude truncated and its sign preserved, converted to type INTEGER(KIND=6).

If A is type COMPLEX, its real part is truncated and converted, and its imaginary part is disgregarded.

See Int Intrinsic.

The precise meaning of this intrinsic might change in a future version of the GNU Fortran language, as more is learned about how it is used.

Sign Intrinsic

Sign(A, B)

Sign: INTEGER or REAL function, the exact type being the result of cross-promoting the types of all the arguments. A: INTEGER or REAL; scalar; INTENT(IN). B: INTEGER or REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns ABS(A)*s, where s is +1 if B.GE.0, -1 otherwise.

See Abs Intrinsic, for the function that returns the magnitude of a value.

Signal Intrinsic (subroutine)

CALL Signal(Number, Handler, Status)

Number: INTEGER; scalar; INTENT(IN). Handler: Signal handler (INTEGER FUNCTION or SUBROUTINE) or dummy/global INTEGER(KIND=1) scalar. Status: INTEGER(KIND=7); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

If Handler is a an EXTERNAL routine, arranges for it to be invoked with a single integer argument (of system-dependent length) when signal Number occurs. If Handler is an integer, it can be used to turn off handling of signal Number or revert to its default action. See signal(2).

Note that Handler will be called using C conventions, so the value of its argument in Fortran terms Fortran terms is obtained by applying %LOC() (or LOC()) to it.

The value returned by signal(2) is written to Status, if that argument is supplied. Otherwise the return value is ignored.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

Warning: Use of the libf2c run-time library function signal_ directly (such as via EXTERNAL SIGNAL) requires use of the %VAL() construct to pass an INTEGER value (such as SIG_IGN or SIG_DFL) for the Handler argument.

However, while CALL SIGNAL(signum, %VAL(SIG_IGN)) works when SIGNAL is treated as an external procedure (and resolves, at link time, to libf2c's signal_ routine), this construct is not valid when SIGNAL is recognized as the intrinsic of that name.

Therefore, for maximum portability and reliability, code such references to the SIGNAL facility as follows:

INTRINSIC SIGNAL
···CALL SIGNAL(signum, SIG_IGN)

g77 will compile such a call correctly, while other compilers will generally either do so as well or reject the INTRINSIC SIGNAL statement via a diagnostic, allowing you to take appropriate action.

For information on other intrinsics with the same name: See Signal Intrinsic (function).

Sin Intrinsic

Sin(X)

Sin: REAL or COMPLEX function, the exact type being that of argument X. X: REAL or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the sine of X, an angle measured in radians.

See ASin Intrinsic, for the inverse of this function.

SinH Intrinsic

SinH(X)

SinH: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the hyperbolic sine of X.

Sleep Intrinsic

CALL Sleep(Seconds)

Seconds: INTEGER(KIND=1); scalar; INTENT(IN). Intrinsic groups: unix. Description:

Causes the process to pause for Seconds seconds. See sleep(2).

Sngl Intrinsic

Sngl(A)

Sngl: REAL(KIND=1) function. A: REAL(KIND=2); scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Archaic form of REAL() that is specific to one type for A. See Real Intrinsic.

Spacing Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Spacing to use this name for an external procedure.

Spread Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Spread to use this name for an external procedure.

SqRt Intrinsic

SqRt(X)

SqRt: REAL or COMPLEX function, the exact type being that of argument X. X: REAL or COMPLEX; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the square root of X, which must not be negative.

To calculate and represent the square root of a negative number, complex arithmetic must be used. For example, SQRT(COMPLEX(X)).

The inverse of this function is SQRT(X) * SQRT(X).

SRand Intrinsic

CALL SRand(Seed)

Seed: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Reinitialises the generator with the seed in Seed. See IRand Intrinsic. See Rand Intrinsic.

Stat Intrinsic (subroutine)

CALL Stat(File, SArray, Status)

File: CHARACTER; scalar; INTENT(IN). SArray: INTEGER(KIND=1); DIMENSION(13); INTENT(OUT). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Obtains data about the given file File and places them in the array SArray. A null character (CHAR(0)) marks the end of the name in File---otherwise, trailing blanks in File are ignored. The values in this array are extracted from the stat structure as returned by fstat(2) q.v., as follows:

1. File mode
2. Inode number
3. ID of device containing directory entry for file
4. Device id (if relevant)
5. Number of links
6. Owner's uid
7. Owner's gid
8. File size (bytes)
9. Last access time
10. Last modification time
11. Last file status change time
12. Preferred I/O block size
13. Number of blocks allocated

Not all these elements are relevant on all systems. If an element is not relevant, it is returned as 0.

If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See Stat Intrinsic (function).

Stat Intrinsic (function)

Stat(File, SArray)

Stat: INTEGER(KIND=1) function. File: CHARACTER; scalar; INTENT(IN). SArray: INTEGER(KIND=1); DIMENSION(13); INTENT(OUT). Intrinsic groups: unix. Description:

Obtains data about the given file File and places them in the array SArray. A null character (CHAR(0)) marks the end of the name in File---otherwise, trailing blanks in File are ignored. The values in this array are extracted from the stat structure as returned by fstat(2) q.v., as follows:

1. File mode
2. Inode number
3. ID of device containing directory entry for file
4. Device id (if relevant)
5. Number of links
6. Owner's uid
7. Owner's gid
8. File size (bytes)
9. Last access time
10. Last modification time
11. Last file status change time
12. Preferred I/O block size
13. Number of blocks allocated

Not all these elements are relevant on all systems. If an element is not relevant, it is returned as 0.

Returns 0 on success or a non-zero error code.

For information on other intrinsics with the same name: See Stat Intrinsic (subroutine).

Sum Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Sum to use this name for an external procedure.

SymLnk Intrinsic (subroutine)

CALL SymLnk(Path1, Path2, Status)

Path1: CHARACTER; scalar; INTENT(IN). Path2: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Makes a symbolic link from file Path1 to Path2. A null character (CHAR(0)) marks the end of the names in Path1 and Path2---otherwise, trailing blanks in Path1 and Path2 are ignored. If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return (ENOSYS if the system does not provide symlink(2)).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See SymLnk Intrinsic (function).

System Intrinsic (subroutine)

CALL System(Command, Status)

Command: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Passes the command Command to a shell (see system(3)). If argument Status is present, it contains the value returned by system(3), presumably 0 if the shell command succeeded. Note that which shell is used to invoke the command is system-dependent and environment-dependent.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See System Intrinsic (function).

System_Clock Intrinsic

CALL System_Clock(Count, Rate, Max)

Count: INTEGER(KIND=1); scalar; INTENT(OUT). Rate: INTEGER(KIND=1); scalar; INTENT(OUT). Max: INTEGER(KIND=1); scalar; INTENT(OUT). Intrinsic groups: f90. Description:

Returns in Count the current value of the system clock; this is the value returned by the UNIX function times(2) in this implementation, but isn't in general. Rate is the number of clock ticks per second and Max is the maximum value this can take, which isn't very useful in this implementation since it's just the maximum C unsigned int value.

Tan Intrinsic

Tan(X)

Tan: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the tangent of X, an angle measured in radians.

See ATan Intrinsic, for the inverse of this function.

TanH Intrinsic

TanH(X)

TanH: REAL function, the KIND= value of the type being that of argument X. X: REAL; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description:

Returns the hyperbolic tangent of X.

Time Intrinsic (UNIX)

Time()

Time: INTEGER(KIND=1) function. Intrinsic groups: unix. Description:

Returns the current time encoded as an integer (in the manner of the UNIX function time(3)). This value is suitable for passing to CTIME, GMTIME, and LTIME.

This intrinsic is not fully portable, such as to systems with 32-bit INTEGER types but supporting times wider than 32 bits. See Time8 Intrinsic, for information on a similar intrinsic that might be portable to more GNU Fortran implementations, though to fewer Fortran compilers.

For information on other intrinsics with the same name: See Time Intrinsic (VXT).

Time8 Intrinsic

Time8()

Time8: INTEGER(KIND=2) function. Intrinsic groups: unix. Description:

Returns the current time encoded as a long integer (in the manner of the UNIX function time(3)). This value is suitable for passing to CTIME, GMTIME, and LTIME.

No Fortran implementations other than GNU Fortran are known to support this intrinsic at the time of this writing. See Time Intrinsic (UNIX), for information on a similar intrinsic that might be portable to more Fortran compilers, though to fewer GNU Fortran implementations.

Tiny Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Tiny to use this name for an external procedure.

Transfer Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Transfer to use this name for an external procedure.

Transpose Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Transpose to use this name for an external procedure.

Trim Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Trim to use this name for an external procedure.

TtyNam Intrinsic (subroutine)

CALL TtyNam(Name, Unit)

Name: CHARACTER; scalar; INTENT(OUT). Unit: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Sets Name to the name of the terminal device open on logical unit Unit or a blank string if Unit is not connected to a terminal.

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See TtyNam Intrinsic (function).

TtyNam Intrinsic (function)

TtyNam(Unit)

TtyNam: CHARACTER*(*) function. Unit: INTEGER; scalar; INTENT(IN). Intrinsic groups: unix. Description:

Returns the name of the terminal device open on logical unit Unit or a blank string if Unit is not connected to a terminal.

For information on other intrinsics with the same name: See TtyNam Intrinsic (subroutine).

UBound Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL UBound to use this name for an external procedure.

UMask Intrinsic (subroutine)

CALL UMask(Mask, Old)

Mask: INTEGER; scalar; INTENT(IN). Old: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Sets the file creation mask to Mask and returns the old value in argument Old if it is supplied. See umask(2).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine.

For information on other intrinsics with the same name: See UMask Intrinsic (function).

Unlink Intrinsic (subroutine)

CALL Unlink(File, Status)

File: CHARACTER; scalar; INTENT(IN). Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT). Intrinsic groups: unix. Description:

Unlink the file File. A null character (CHAR(0)) marks the end of the name in File---otherwise, trailing blanks in File are ignored. If the Status argument is supplied, it contains 0 on success or a non-zero error code upon return. See unlink(2).

Some non-GNU implementations of Fortran provide this intrinsic as only a function, not as a subroutine, or do not support the (optional) Status argument.

For information on other intrinsics with the same name: See Unlink Intrinsic (function).

Unpack Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Unpack to use this name for an external procedure.

Verify Intrinsic

This intrinsic is not yet implemented. The name is, however, reserved as an intrinsic. Use EXTERNAL Verify to use this name for an external procedure.

XOr Intrinsic

XOr(I, J)

XOr: INTEGER or LOGICAL function, the exact type being the result of cross-promoting the types of all the arguments. I: INTEGER or LOGICAL; scalar; INTENT(IN). J: INTEGER or LOGICAL; scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Returns value resulting from boolean exclusive-OR of pair of bits in each of I and J.

ZAbs Intrinsic

ZAbs(A)

ZAbs: REAL(KIND=2) function. A: COMPLEX(KIND=2); scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Archaic form of ABS() that is specific to one type for A. See Abs Intrinsic.

ZCos Intrinsic

ZCos(X)

ZCos: COMPLEX(KIND=2) function. X: COMPLEX(KIND=2); scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Archaic form of COS() that is specific to one type for X. See Cos Intrinsic.

ZExp Intrinsic

ZExp(X)

ZExp: COMPLEX(KIND=2) function. X: COMPLEX(KIND=2); scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Archaic form of EXP() that is specific to one type for X. See Exp Intrinsic.

ZLog Intrinsic

ZLog(X)

ZLog: COMPLEX(KIND=2) function. X: COMPLEX(KIND=2); scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Archaic form of LOG() that is specific to one type for X. See Log Intrinsic.

ZSin Intrinsic

ZSin(X)

ZSin: COMPLEX(KIND=2) function. X: COMPLEX(KIND=2); scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Archaic form of SIN() that is specific to one type for X. See Sin Intrinsic.

ZSqRt Intrinsic

ZSqRt(X)

ZSqRt: COMPLEX(KIND=2) function. X: COMPLEX(KIND=2); scalar; INTENT(IN). Intrinsic groups: f2c. Description:

Archaic form of SQRT() that is specific to one type for X. See SqRt Intrinsic.

Scope and Classes of Symbolic Names

(The following information augments or overrides the information in Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 18 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.)

• Underscores in Symbol Names

Underscores in Symbol Names

Underscores (_) are accepted in symbol names after the first character (which must be a letter).

Other Dialects

GNU Fortran supports a variety of features that are not considered part of the GNU Fortran language itself, but are representative of various dialects of Fortran that g77 supports in whole or in part.

Any of the features listed below might be disallowed by g77 unless some command-line option is specified. Currently, some of the features are accepted using the default invocation of g77, but that might change in the future.

Note: This portion of the documentation definitely needs a lot of work!

• Details of fixed-form and free-form source.
• Use of /* to start a comment.
• Use of D in column 1.
• Use of $ in symbolic names.
• Uppercase and lowercase in source files.
• ···versus the GNU Fortran language.
• ···versus the GNU Fortran language.
• Enforcing the standard.
• Misfeatures supported by GNU Fortran.

Source Form

GNU Fortran accepts programs written in either fixed form or free form.

Fixed form corresponds to ANSI FORTRAN 77 (plus popular extensions, such as allowing tabs) and Fortran 90's fixed form.

Free form corresponds to Fortran 90's free form (though possibly not entirely up-to-date, and without complaining about some things that for which Fortran 90 requires diagnostics, such as the spaces in the constant in R = 3 . 1).

The way a Fortran compiler views source files depends entirely on the implementation choices made for the compiler, since those choices are explicitly left to the implementation by the published Fortran standards. GNU Fortran currently tries to be somewhat like a few popular compilers (f2c, Digital (``DEC'') Fortran, and so on), though a cleaner default definition along with more flexibility offered by command-line options is likely to be offered in version 0.6.

This section describes how g77 interprets source lines.

• Carriage returns ignored.
• Tabs converted to spaces.
• Short lines padded with spaces (fixed-form only).
• Long lines truncated.
• Special Continuation Lines.

Carriage Returns

Carriage returns (\r) in source lines are ignored. This is somewhat different from f2c, which seems to treat them as spaces outside character/Hollerith constants, and encodes them as \r inside such constants.

Tabs

A source line with a TAB character anywhere in it is treated as entirely significant---however long it is---instead of ending in column 72 (for fixed-form source) or 132 (for free-form source). This also is different from f2c, which encodes tabs as \t (the ASCII TAB character) inside character and Hollerith constants, but nevertheless seems to treat the column position as if it had been affected by the canonical tab positioning.

g77 effectively translates tabs to the appropriate number of spaces (a la the default for the UNIX expand command) before doing any other processing, other than (currently) noting whether a tab was found on a line and using this information to decide how to interpret the length of the line and continued constants.

Note that this default behavior probably will change for version 0.6, when it will presumably be available via a command-line option. The default as of version 0.6 is planned to be a ``pure visual'' model, where tabs are immediately converted to spaces and otherwise have no effect, so the way a typical user sees source lines produces a consistent result no matter how the spacing in those source lines is actually implemented via tabs, spaces, and trailing tabs/spaces before newline. Command-line options are likely to be added to specify whether all or just-tabbed lines are to be extended to 132 or full input-line length, and perhaps even an option will be added to specify the truncated-line behavior to which some Digital compilers default (and which affects the way continued character/Hollerith constants are interpreted).

Short Lines

Source lines shorter than the applicable fixed-form length are treated as if they were padded with spaces to that length. (None of this is relevant to source files written in free form.)

This affects only continued character and Hollerith constants, and is a different interpretation than provided by some other popular compilers (although a bit more consistent with the traditional punched-card basis of Fortran and the way the Fortran standard expressed fixed source form).

g77 might someday offer an option to warn about cases where differences might be seen as a result of this treatment, and perhaps an option to specify the alternate behavior as well.

Note that this padding cannot apply to lines that are effectively of infinite length---such lines are specified using command-line options like -ffixed-line-length-none, for example.

Long Lines

Source lines longer than the applicable length are truncated to that length. Currently, g77 does not warn if the truncated characters are not spaces, to accommodate existing code written for systems that treated truncated text as commentary (especially in columns 73 through 80).

See Options Controlling Fortran Dialect, for information on the -ffixed-line-length-n option, which can be used to set the line length applicable to fixed-form source files.

Ampersand Continuation Line

A & in column 1 of fixed-form source denotes an arbitrary-length continuation line, imitating the behavior of f2c.

Trailing Comment

g77 supports use of /* to start a trailing comment. In the GNU Fortran language, ! is used for this purpose.

/* is not in the GNU Fortran language because the use of /* in a program might suggest to some readers that a block, not trailing, comment is started (and thus ended by */, not end of line), since that is the meaning of /* in C.

Also, such readers might think they can use // to start a trailing comment as an alternative to /*, but // already denotes concatenation, and such a ``comment'' might actually result in a program that compiles without error (though it would likely behave incorrectly).

Debug Line

Use of D or d as the first character (column 1) of a source line denotes a debug line.

In turn, a debug line is treated as either a comment line or a normal line, depending on whether debug lines are enabled.

When treated as a comment line, a line beginning with D or d is treated as if it the first character was C or c, respectively. When treated as a normal line, such a line is treated as if the first character was SPC (space).

(Currently, g77 provides no means for treating debug lines as normal lines.)

Dollar Signs in Symbol Names

Dollar signs ($) are allowed in symbol names (after the first character) when the -fdollar-ok option is specified.

Case Sensitivity

GNU Fortran offers the programmer way too much flexibility in deciding how source files are to be treated vis-a-vis uppercase and lowercase characters. There are 66 useful settings that affect case sensitivity, plus 10 settings that are nearly useless, with the remaining 116 settings being either redundant or useless.

None of these settings have any effect on the contents of comments (the text after a c or C in Column 1, for example) or of character or Hollerith constants. Note that things like the E in the statement CALL FOO(3.2E10) and the TO in ASSIGN 10 TO LAB are considered built-in keywords, and so are affected by these settings.

Low-level switches are identified in this section as follows:

• A
  Source Case Conversion:
  • 0
    Preserve (see Note 1)
  • 1
    Convert to Upper Case
  • 2
    Convert to Lower Case
• B
  Built-in Keyword Matching:
  • 0
    Match Any Case (per-character basis)
  • 1
    Match Upper Case Only
  • 2
    Match Lower Case Only
  • 3
    Match InitialCaps Only (see tables for spellings)
• C
  Built-in Intrinsic Matching:
  • 0
    Match Any Case (per-character basis)
  • 1
    Match Upper Case Only
  • 2
    Match Lower Case Only
  • 3
    Match InitialCaps Only (see tables for spellings)
• D
  User-defined Symbol Possibilities (warnings only):
  • 0
    Allow Any Case (per-character basis)
  • 1
    Allow Upper Case Only
  • 2
    Allow Lower Case Only
  • 3
    Allow InitialCaps Only (see Note 2)

Note 1: g77 eventually will support NAMELIST in a manner that is consistent with these source switches---in the sense that input will be expected to meet the same requirements as source code in terms of matching symbol names and keywords (for the exponent letters).

Currently, however, NAMELIST is supported by libf2c, which uppercases NAMELIST input and symbol names for matching. This means not only that NAMELIST output currently shows symbol (and keyword) names in uppercase even if lower-case source conversion (option A2) is selected, but that NAMELIST cannot be adequately supported when source case preservation (option A0) is selected.

If A0 is selected, a warning message will be output for each NAMELIST statement to this effect. The behavior of the program is undefined at run time if two or more symbol names appear in a given NAMELIST such that the names are identical when converted to upper case (e.g. NAMELIST /X/ VAR, Var, var). For complete and total elegance, perhaps there should be a warning when option A2 is selected, since the output of NAMELIST is currently in uppercase but will someday be lowercase (when a libg77 is written), but that seems to be overkill for a product in beta test.

Note 2: Rules for InitialCaps names are:

• Must be a single uppercase letter, or
• Must start with an uppercase letter and contain at least one lowercase letter.

So A, Ab, ABc, AbC, and Abc are valid InitialCaps names, but AB, A2, and ABC are not. Note that most, but not all, built-in names meet these requirements---the exceptions are some of the two-letter format specifiers, such as BN and BZ.

Here are the names of the corresponding command-line options:

A0: -fsource-case-preserve
A1: -fsource-case-upper
A2: -fsource-case-lower
B0: -fmatch-case-any
B1: -fmatch-case-upper
B2: -fmatch-case-lower
B3: -fmatch-case-initcap
C0: -fintrin-case-any
C1: -fintrin-case-upper
C2: -fintrin-case-lower
C3: -fintrin-case-initcap
D0: -fsymbol-case-any
D1: -fsymbol-case-upper
D2: -fsymbol-case-lower
D3: -fsymbol-case-initcap

Useful combinations of the above settings, along with abbreviated option names that set some of these combinations all at once:

 1: A0--  B0---  C0---  D0---    -fcase-preserve
 2: A0--  B0---  C0---  D-1--
 3: A0--  B0---  C0---  D--2-
 4: A0--  B0---  C0---  D---3
 5: A0--  B0---  C-1--  D0---
 6: A0--  B0---  C-1--  D-1--
 7: A0--  B0---  C-1--  D--2-
 8: A0--  B0---  C-1--  D---3
 9: A0--  B0---  C--2-  D0---
10: A0--  B0---  C--2-  D-1--
11: A0--  B0---  C--2-  D--2-
12: A0--  B0---  C--2-  D---3
13: A0--  B0---  C---3  D0---
14: A0--  B0---  C---3  D-1--
15: A0--  B0---  C---3  D--2-
16: A0--  B0---  C---3  D---3
17: A0--  B-1--  C0---  D0---
18: A0--  B-1--  C0---  D-1--
19: A0--  B-1--  C0---  D--2-
20: A0--  B-1--  C0---  D---3
21: A0--  B-1--  C-1--  D0---
22: A0--  B-1--  C-1--  D-1--    -fcase-strict-upper
23: A0--  B-1--  C-1--  D--2-
24: A0--  B-1--  C-1--  D---3
25: A0--  B-1--  C--2-  D0---
26: A0--  B-1--  C--2-  D-1--
27: A0--  B-1--  C--2-  D--2-
28: A0--  B-1--  C--2-  D---3
29: A0--  B-1--  C---3  D0---
30: A0--  B-1--  C---3  D-1--
31: A0--  B-1--  C---3  D--2-
32: A0--  B-1--  C---3  D---3
33: A0--  B--2-  C0---  D0---
34: A0--  B--2-  C0---  D-1--
35: A0--  B--2-  C0---  D--2-
36: A0--  B--2-  C0---  D---3
37: A0--  B--2-  C-1--  D0---
38: A0--  B--2-  C-1--  D-1--
39: A0--  B--2-  C-1--  D--2-
40: A0--  B--2-  C-1--  D---3
41: A0--  B--2-  C--2-  D0---
42: A0--  B--2-  C--2-  D-1--
43: A0--  B--2-  C--2-  D--2-    -fcase-strict-lower
44: A0--  B--2-  C--2-  D---3
45: A0--  B--2-  C---3  D0---
46: A0--  B--2-  C---3  D-1--
47: A0--  B--2-  C---3  D--2-
48: A0--  B--2-  C---3  D---3
49: A0--  B---3  C0---  D0---
50: A0--  B---3  C0---  D-1--
51: A0--  B---3  C0---  D--2-
52: A0--  B---3  C0---  D---3
53: A0--  B---3  C-1--  D0---
54: A0--  B---3  C-1--  D-1--
55: A0--  B---3  C-1--  D--2-
56: A0--  B---3  C-1--  D---3
57: A0--  B---3  C--2-  D0---
58: A0--  B---3  C--2-  D-1--
59: A0--  B---3  C--2-  D--2-
60: A0--  B---3  C--2-  D---3
61: A0--  B---3  C---3  D0---
62: A0--  B---3  C---3  D-1--
63: A0--  B---3  C---3  D--2-
64: A0--  B---3  C---3  D---3    -fcase-initcap
65: A-1-  B01--  C01--  D01--    -fcase-upper
66: A--2  B0-2-  C0-2-  D0-2-    -fcase-lower

Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input (except comments, character constants, and Hollerith strings) must be entered in uppercase. Use -fcase-strict-upper to specify this combination.

Number 43 is like Number 22 except all input must be lowercase. Use -fcase-strict-lower to specify this combination.

Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many non-UNIX machines whereby all the source is translated to uppercase. Use -fcase-upper to specify this combination.

Number 66 is the ``canonical'' UNIX model whereby all the source is translated to lowercase. Use -fcase-lower to specify this combination.

There are a few nearly useless combinations:

67: A-1-  B01--  C01--  D--2-
68: A-1-  B01--  C01--  D---3
69: A-1-  B01--  C--23  D01--
70: A-1-  B01--  C--23  D--2-
71: A-1-  B01--  C--23  D---3
72: A--2  B01--  C0-2-  D-1--
73: A--2  B01--  C0-2-  D---3
74: A--2  B01--  C-1-3  D0-2-
75: A--2  B01--  C-1-3  D-1--
76: A--2  B01--  C-1-3  D---3

The above allow some programs to be compiled but with restrictions that make most useful programs impossible: Numbers 67 and 72 warn about any user-defined symbol names (such as SUBROUTINE FOO); Numbers 68 and 73 warn about any user-defined symbol names longer than one character that don't have at least one non-alphabetic character after the first; Numbers 69 and 74 disallow any references to intrinsics; and Numbers 70, 71, 75, and 76 are combinations of the restrictions in 67+69, 68+69, 72+74, and 73+74, respectively.

All redundant combinations are shown in the above tables anyplace where more than one setting is shown for a low-level switch. For example, B0-2- means either setting 0 or 2 is valid for switch B. The ``proper'' setting in such a case is the one that copies the setting of switch A---any other setting might slightly reduce the speed of the compiler, though possibly to an unmeasurable extent.

All remaining combinations are useless in that they prevent successful compilation of non-null source files (source files with something other than comments).

VXT Fortran

g77 supports certain constructs that have different meanings in VXT Fortran than they do in the GNU Fortran language.

Generally, this manual uses the invented term VXT Fortran to refer VAX FORTRAN (circa v4). That compiler offered many popular features, though not necessarily those that are specific to the VAX processor architecture, the VMS operating system, or Digital Equipment Corporation's Fortran product line. (VAX and VMS probably are trademarks of Digital Equipment Corporation.)

An extension offered by a Digital Fortran product that also is offered by several other Fortran products for different kinds of systems is probably going to be considered for inclusion in g77 someday, and is considered a VXT Fortran feature.

The -fvxt option generally specifies that, where the meaning of a construct is ambiguous (means one thing in GNU Fortran and another in VXT Fortran), the VXT Fortran meaning is to be assumed.

• "2000 as octal constant.
• ! in column 6.

Meaning of Double Quote

g77 treats double-quote (") as beginning an octal constant of INTEGER(KIND=1) type when the -fvxt option is specified. The form of this octal constant is

"octal-digits

where octal-digits is a nonempty string of characters in the set 01234567.

For example, the -fvxt option permits this:

PRINT *, "20
END

The above program would print the value 16.

See Integer Type, for information on the preferred construct for integer constants specified using GNU Fortran's octal notation.

(In the GNU Fortran language, the double-quote character (") delimits a character constant just as does apostrophe ('). There is no way to allow both constructs in the general case, since statements like PRINT *,"2000 !comment?" would be ambiguous.)

Meaning of Exclamation Point in Column 6

g77 treats an exclamation point (!) in column 6 of a fixed-form source file as a continuation character rather than as the beginning of a comment (as it does in any other column) when the -fvxt option is specified.

The following program, when run, prints a message indicating whether it is interpreted according to GNU Fortran (and Fortran 90) rules or VXT Fortran rules:

C234567  (This line begins in column 1.)
      I = 0
     !1
      IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
      IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
      IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
      END

(In the GNU Fortran and Fortran 90 languages, exclamation point is a valid character and, unlike space (SPC) or zero (0), marks a line as a continuation line when it appears in column 6.)

Fortran 90

The GNU Fortran language includes a number of features that are part of Fortran 90, even when the -ff90 option is not specified. The features enabled by -ff90 are intended to be those that, when -ff90 is not specified, would have another meaning to g77---usually meaning something invalid in the GNU Fortran language.

So, the purpose of -ff90 is not to specify whether g77 is to gratuitously reject Fortran 90 constructs. The -pedantic option specified with -fno-f90 is intended to do that, although its implementation is certainly incomplete at this point.

When -ff90 is specified:

• The type of REAL(expr) and AIMAG(expr), where expr is COMPLEX type, is the same type as the real part of expr.

  For example, assuming Z is type COMPLEX(KIND=2), REAL(Z) would return a value of type REAL(KIND=2), not of type REAL(KIND=1), since -ff90 is specified.

Pedantic Compilation

The -fpedantic command-line option specifies that g77 is to warn about code that is not standard-conforming. This is useful for finding some extensions g77 accepts that other compilers might not accept. (Note that the -pedantic and -pedantic-errors options always imply -fpedantic.)

With -fno-f90 in force, ANSI FORTRAN 77 is used as the standard for conforming code. With -ff90 in force, Fortran 90 is used.

The constructs for which g77 issues diagnostics when -fpedantic and -fno-f90 are in force are:

• Automatic arrays, as in

  SUBROUTINE X(N)
  REAL A(N)
  ···

  where A is not listed in any ENTRY statement, and thus is not a dummy argument.
• The commas in READ (5), I and WRITE (10), J.

  These commas are disallowed by FORTRAN 77, but, while strictly superfluous, are syntactically elegant, especially given that commas are required in statements such as READ 99, I and PRINT *, J. Many compilers permit the superfluous commas for this reason.

• DOUBLE COMPLEX, either explicitly or implicitly.

  An explicit use of this type is via a DOUBLE COMPLEX or IMPLICIT DOUBLE COMPLEX statement, for examples.

  An example of an implicit use is the expression C*D, where C is COMPLEX(KIND=1) and D is DOUBLE PRECISION. This expression is prohibited by ANSI FORTRAN 77 because the rules of promotion would suggest that it produce a DOUBLE COMPLEX result---a type not provided for by that standard.

• Automatic conversion of numeric expressions to INTEGER(KIND=1) in contexts such as:
  • Array-reference indexes.
  • Alternate-return values.
  • Computed GOTO.
  • FORMAT run-time expressions (not yet supported).
  • Dimension lists in specification statements.
  • Numbers for I/O statements (such as READ (UNIT=3.2), I)
  • Sizes of CHARACTER entities in specification statements.
  • Kind types in specification entities (a Fortran 90 feature).
  • Initial, terminal, and incrementation parameters for implied-DO constructs in DATA statements.
• Automatic conversion of LOGICAL expressions to INTEGER in contexts such as arithmetic IF (where COMPLEX expressions are disallowed anyway).
• Zero-size array dimensions, as in:

  INTEGER I(10,20,4:2)
  

• Zero-length CHARACTER entities, as in:

  PRINT *, ''
  

• Substring operators applied to character constants and named constants, as in:

  PRINT *, 'hello'(3:5)
  

• Null arguments passed to statement function, as in:

  PRINT *, FOO(,3)
  

• Disagreement among program units regarding whether a given COMMON area is SAVEd (for targets where program units in a single source file are ``glued'' together as they typically are for UNIX development environments).
• Disagreement among program units regarding the size of a named COMMON block.
• Specification statements following first DATA statement.

  (In the GNU Fortran language, DATA I/1/ may be followed by INTEGER J, but not INTEGER I. The -fpedantic option disallows both of these.)

• Semicolon as statement separator, as in:

  CALL FOO; CALL BAR
  

• Use of & in column 1 of fixed-form source (to indicate continuation).
• Use of CHARACTER constants to initialize numeric entities, and vice versa.
• Expressions having two arithmetic operators in a row, such as X*-Y.

If -fpedantic is specified along with -ff90, the following constructs result in diagnostics:

• Use of semicolon as a statement separator on a line that has an INCLUDE directive.

Distensions

The -fugly-* command-line options determine whether certain features supported by VAX FORTRAN and other such compilers, but considered too ugly to be in code that can be changed to use safer and/or more portable constructs, are accepted. These are humorously referred to as ``distensions'', extensions that just plain look ugly in the harsh light of day.

Note: The -fugly option, which currently serves as shorthand to enable all of the distensions below, is likely to be removed in a future version of g77. That's because it's likely new distensions will be added that conflict with existing ones in terms of assigning meaning to a given chunk of code. (Also, it's pretty clear that users should not use -fugly as shorthand when the next release of g77 might add a distension to that that causes their existing code, when recompiled, to behave differently---perhaps even fail to compile or run correctly.)

• Disabled via -fno-ugly-args.
• Enabled via -fugly-assumed.
• Enabled via -fugly-comma.
• Enabled via -fugly-complex.
• Disabled via -fno-ugly-init.
• Enabled via -fugly-logint.
• Enabled via -fugly-assign.

Implicit Argument Conversion

The -fno-ugly-args option disables passing typeless and Hollerith constants as actual arguments in procedure invocations. For example:

CALL FOO(4HABCD)
CALL BAR('123'O)

These constructs can be too easily used to create non-portable code, but are not considered as ``ugly'' as others. Further, they are widely used in existing Fortran source code in ways that often are quite portable. Therefore, they are enabled by default.

Ugly Assumed-Size Arrays

The -fugly-assumed option enables the treatment of any array with a final dimension specified as 1 as an assumed-size array, as if * had been specified instead.

For example, DIMENSION X(1) is treated as if it had read DIMENSION X(*) if X is listed as a dummy argument in a preceding SUBROUTINE, FUNCTION, or ENTRY statement in the same program unit.

Use an explicit lower bound to avoid this interpretation. For example, DIMENSION X(1:1) is never treated as if it had read DIMENSION X(*) or DIMENSION X(1:*). Nor is DIMENSION X(2-1) affected by this option, since that kind of expression is unlikely to have been intended to designate an assumed-size array.

This option is used to prevent warnings being issued about apparent out-of-bounds reference such as X(2) = 99.

It also prevents the array from being used in contexts that disallow assumed-size arrays, such as PRINT *,X. In such cases, a diagnostic is generated and the source file is not compiled.

The construct affected by this option is used only in old code that pre-exists the widespread acceptance of adjustable and assumed-size arrays in the Fortran community.

Note: This option does not affect how DIMENSION X(1) is treated if X is listed as a dummy argument only after the DIMENSION statement (presumably in an ENTRY statement). For example, -fugly-assumed has no effect on the following program unit:

SUBROUTINE X
REAL A(1)
RETURN
ENTRY Y(A)
PRINT *, A
END

Ugly Complex Part Extraction

The -fugly-complex option enables use of the REAL() and AIMAG() intrinsics with arguments that are COMPLEX types other than COMPLEX(KIND=1).

With -ff90 in effect, these intrinsics return the unconverted real and imaginary parts (respectively) of their argument.

With -fno-f90 in effect, these intrinsics convert the real and imaginary parts to REAL(KIND=1), and return the result of that conversion.

Due to this ambiguity, the GNU Fortran language defines these constructs as invalid, except in the specific case where they are entirely and solely passed as an argument to an invocation of the REAL() intrinsic. For example,

REAL(REAL(Z))

is permitted even when Z is COMPLEX(KIND=2) and -fno-ugly-complex is in effect, because the meaning is clear.

g77 enforces this restriction, unless -fugly-complex is specified, in which case the appropriate interpretation is chosen and no diagnostic is issued.

See CMPAMBIG, for information on how to cope with existing code with unclear expectations of REAL() and AIMAG() with COMPLEX(KIND=2) arguments.

See RealPart Intrinsic, for information on the REALPART() intrinsic, used to extract the real part of a complex expression without conversion. See ImagPart Intrinsic, for information on the IMAGPART() intrinsic, used to extract the imaginary part of a complex expression without conversion.

Ugly Null Arguments

The -fugly-comma option enables use of a single trailing comma to mean ``pass an extra trailing null argument'' in a list of actual arguments to an external procedure, and use of an empty list of arguments to such a procedure to mean ``pass a single null argument''.

(Null arguments often are used in some procedure-calling schemes to indicate omitted arguments.)

For example, CALL FOO(,) means ``pass two null arguments'', rather than ``pass one null argument''. Also, CALL BAR() means ``pass one null argument''.

This construct is considered ``ugly'' because it does not provide an elegant way to pass a single null argument that is syntactically distinct from passing no arguments. That is, this construct changes the meaning of code that makes no use of the construct.

So, with -fugly-comma in force, CALL FOO() and I = JFUNC() pass a single null argument, instead of passing no arguments as required by the Fortran 77 and 90 standards.

Note: Many systems gracefully allow the case where a procedure call passes one extra argument that the called procedure does not expect.

So, in practice, there might be no difference in the behavior of a program that does CALL FOO() or I = JFUNC() and is compiled with -fugly-comma in force as compared to its behavior when compiled with the default, -fno-ugly-comma, in force, assuming FOO and JFUNC do not expect any arguments to be passed.

Ugly Conversion of Initializers

The constructs disabled by -fno-ugly-init are:

• Use of Hollerith and typeless constants in contexts where they set initial (compile-time) values for variables, arrays, and named constants---that is, DATA and PARAMETER statements, plus type-declaration statements specifying initial values.

  Here are some sample initializations that are disabled by the -fno-ugly-init option:

  PARAMETER (VAL='9A304FFE'X)
  REAL*8 STRING/8HOUTPUT00/
  DATA VAR/4HABCD/
  

• In the same contexts as above, use of character constants to initialize numeric items and vice versa (one constant per item).

  Here are more sample initializations that are disabled by the -fno-ugly-init option:

  INTEGER IA
  CHARACTER BELL
  PARAMETER (IA = 'A')
  PARAMETER (BELL = 7)
  

• Use of Hollerith and typeless constants on the right-hand side of assignment statements to numeric types, and in other contexts (such as passing arguments in invocations of intrinsic procedures and statement functions) that are treated as assignments to known types (the dummy arguments, in these cases).

  Here are sample statements that are disabled by the -fno-ugly-init option:

  IVAR = 4HABCD
  PRINT *, IMAX0(2HAB, 2HBA)
  

The above constructs, when used, can tend to result in non-portable code. But, they are widely used in existing Fortran code in ways that often are quite portable. Therefore, they are enabled by default.

Ugly Integer Conversions

The constructs enabled via -fugly-logint are:

• Automatic conversion between INTEGER and LOGICAL as dictated by context (typically implies nonportable dependencies on how a particular implementation encodes .TRUE. and .FALSE.).
• Use of a LOGICAL variable in ASSIGN and assigned-GOTO statements.

The above constructs are disabled by default because use of them tends to lead to non-portable code. Even existing Fortran code that uses that often turns out to be non-portable, if not outright buggy.

Some of this is due to differences among implementations as far as how .TRUE. and .FALSE. are encoded as INTEGER values---Fortran code that assumes a particular coding is likely to use one of the above constructs, and is also likely to not work correctly on implementations using different encodings.

See Equivalence Versus Equality, for more information.

Ugly Assigned Labels

The -fugly-assign option forces g77 to use the same storage for assigned labels as it would for a normal assignment to the same variable.

For example, consider the following code fragment:

I = 3
ASSIGN 10 TO I

Normally, for portability and improved diagnostics, g77 reserves distinct storage for a ``sibling'' of I, used only for ASSIGN statements to that variable (along with the corresponding assigned-GOTO and assigned-FORMAT-I/O statements that reference the variable).

However, some code (that violates the ANSI FORTRAN 77 standard) attempts to copy assigned labels among variables involved with ASSIGN statements, as in:

ASSIGN 10 TO I
ISTATE(5) = I
···J = ISTATE(ICUR)
GOTO J

Such code doesn't work under g77 unless -fugly-assign is specified on the command-line, ensuring that the value of I referenced in the second line is whatever value g77 uses to designate statement label 10, so the value may be copied into the ISTATE array, later retrieved into a variable of the appropriate type (J), and used as the target of an assigned-GOTO statement.

Note: To avoid subtle program bugs, when -fugly-assign is specified, g77 requires the type of variables specified in assigned-label contexts must be the same type returned by %LOC(). On many systems, this type is effectively the same as INTEGER(KIND=1), while, on others, it is effectively the same as INTEGER(KIND=2).

Do not depend on g77 actually writing valid pointers to these variables, however. While g77 currently chooses that implementation, it might be changed in the future.

See Assigned Statement Labels (ASSIGN and GOTO), for implementation details on assigned-statement labels.

The GNU Fortran Compiler

The GNU Fortran compiler, g77, supports programs written in the GNU Fortran language and in some other dialects of Fortran.

Some aspects of how g77 works are universal regardless of dialect, and yet are not properly part of the GNU Fortran language itself. These are described below.

Note: This portion of the documentation definitely needs a lot of work!

• Compiler Limits
• Compiler Types
• Compiler Constants
• Compiler Intrinsics

Compiler Limits

g77, as with GNU tools in general, imposes few arbitrary restrictions on lengths of identifiers, number of continuation lines, number of external symbols in a program, and so on.

For example, some other Fortran compiler have an option (such as -Nlx) to increase the limit on the number of continuation lines. Also, some Fortran compilation systems have an option (such as -Nxx) to increase the limit on the number of external symbols.

g77, gcc, and GNU ld (the GNU linker) have no equivalent options, since they do not impose arbitrary limits in these areas.

g77 does currently limit the number of dimensions in an array to the same degree as do the Fortran standards---seven (7). This restriction might well be lifted in a future version.

Compiler Types

Fortran implementations have a fair amount of freedom given them by the standard as far as how much storage space is used and how much precision and range is offered by the various types such as LOGICAL(KIND=1), INTEGER(KIND=1), REAL(KIND=1), REAL(KIND=2), COMPLEX(KIND=1), and CHARACTER. Further, many compilers offer so-called *n notation, but the interpretation of n varies across compilers and target architectures.

The standard requires that LOGICAL(KIND=1), INTEGER(KIND=1), and REAL(KIND=1) occupy the same amount of storage space, and that COMPLEX(KIND=1) and REAL(KIND=2) take twice as much storage space as REAL(KIND=1). Further, it requires that COMPLEX(KIND=1) entities be ordered such that when a COMPLEX(KIND=1) variable is storage-associated (such as via EQUIVALENCE) with a two-element REAL(KIND=1) array named R, R(1) corresponds to the real element and R(2) to the imaginary element of the COMPLEX(KIND=1) variable.

(Few requirements as to precision or ranges of any of these are placed on the implementation, nor is the relationship of storage sizes of these types to the CHARACTER type specified, by the standard.)

g77 follows the above requirements, warning when compiling a program requires placement of items in memory that contradict the requirements of the target architecture. (For example, a program can require placement of a REAL(KIND=2) on a boundary that is not an even multiple of its size, but still an even multiple of the size of a REAL(KIND=1) variable. On some target architectures, using the canonical mapping of Fortran types to underlying architectural types, such placement is prohibited by the machine definition or the Application Binary Interface (ABI) in force for the configuration defined for building gcc and g77. g77 warns about such situations when it encounters them.)

g77 follows consistent rules for configuring the mapping between Fortran types, including the *n notation, and the underlying architectural types as accessed by a similarly-configured applicable version of the gcc compiler. These rules offer a widely portable, consistent Fortran/C environment, although they might well conflict with the expectations of users of Fortran compilers designed and written for particular architectures.

These rules are based on the configuration that is in force for the version of gcc built in the same release as g77 (and which was therefore used to build both the g77 compiler components and the libf2c run-time library):

REAL(KIND=1)


Same as float type.

REAL(KIND=2)


Same as whatever floating-point type that is twice the size of a float---usually, this is a double.

INTEGER(KIND=1)


Same as an integral type that is occupies the same amount of memory storage as float---usually, this is either an int or a long int.

LOGICAL(KIND=1)


Same gcc type as INTEGER(KIND=1).

INTEGER(KIND=2)


Twice the size, and usually nearly twice the range, as INTEGER(KIND=1)---usually, this is either a long int or a long long int.

LOGICAL(KIND=2)


Same gcc type as INTEGER(KIND=2).

INTEGER(KIND=3)


Same gcc type as signed char.

LOGICAL(KIND=3)


Same gcc type as INTEGER(KIND=3).

INTEGER(KIND=6)


Twice the size, and usually nearly twice the range, as INTEGER(KIND=3)---usually, this is a short.

LOGICAL(K