The name of this utility was chosen as fort77 to parallel the
renaming of the C compiler. The name f77 was not chosen to avoid
problems with historical implementations. The ANSI X3.9‐1978
standard was selected as a normative reference because the
ISO/IEC version of FORTRAN-77 has been superseded by the
ISO/IEC 1539:1991 standard.
The file inclusion and symbol definition #define mechanisms used
by the c99 utility were not included in this volume of
POSIX.1‐2017—even though they are commonly implemented—since
there is no requirement that the FORTRAN compiler use the C
preprocessor.
The -onetrip option was not included in this volume of
POSIX.1‐2017, even though many historical compilers support it,
because it is derived from FORTRAN-66; it is an anachronism that
should not be perpetuated.
Some implementations produce compilation listings. This aspect of
FORTRAN has been left unspecified because there was controversy
concerning the various methods proposed for implementing it: a -V
option overlapped with historical vendor practice and a naming
convention of creating files with .l suffixes collided with
historical lex file naming practice.
There is no -I option in this version of this volume of
POSIX.1‐2017 to specify a directory for file inclusion. An
INCLUDE directive has been a part of the Fortran-90 discussions,
but an interface supporting that standard is not in the current
scope.
It is noted that many FORTRAN compilers produce an object module
even when compilation errors occur; during a subsequent
compilation, the compiler may patch the object module rather than
recompiling all the code. Consequently, it is left to the
implementor whether or not an object file is created.
A reference to MIL-STD-1753 was removed from an early proposal in
response to a request from the POSIX FORTRAN-binding standard
developers. It was not the intention of the standard developers
to require certification of the FORTRAN compiler, and
IEEE Std 1003.9‐1992 does not specify the military standard or
any special preprocessing requirements. Furthermore, use of that
document would have been inappropriate for an international
standard.
The specification of optimization has been subject to changes
through early proposals. At one time, -O and -N were Booleans:
optimize and do not optimize (with an unspecified default). Some
historical practice led this to be changed to:
-O 0 No optimization.
-O 1 Some level of optimization.
-O n Other, unspecified levels of optimization.
It is not always clear whether ``good code generation'' is the
same thing as optimization. Simple optimizations of local actions
do not usually affect the semantics of a program. The -O 0 option
has been included to accommodate the very particular nature of
scientific calculations in a highly optimized environment;
compilers make errors. Some degree of optimization is expected,
even if it is not documented here, and the ability to shut it off
completely could be important when porting an application. An
implementation may treat -O 0 as ``do less than normal'' if it
wishes, but this is only meaningful if any of the operations it
performs can affect the semantics of a program. It is highly
dependent on the implementation whether doing less than normal is
logical. It is not the intent of the -O 0 option to ask for
inefficient code generation, but rather to assure that any
semantically visible optimization is suppressed.
The specification of standard library access is consistent with
the C compiler specification. Implementations are not required to
have /usr/lib/libf.a, as many historical implementations do, but
if not they are required to recognize f as a token.
External symbol size limits are in normative text; conforming
applications need to know these limits. However, the minimum
maximum symbol length should be taken as a constraint on a
conforming application, not on an implementation, and
consequently the action taken for a symbol exceeding the limit is
unspecified. The minimum size for the external symbol table was
added for similar reasons.
The CONSEQUENCES OF ERRORS section clearly specifies the behavior
of the compiler when compilation or link-edit errors occur. The
behavior of several historical implementations was examined, and
the choice was made to be silent on the status of the executable,
or a.out, file in the face of compiler or linker errors. If a
linker writes the executable file, then links it on disk with
lseek()s and write()s, the partially linked executable file can
be left on disk and its execute bits turned off if the link edit
fails. However, if the linker links the image in memory before
writing the file to disk, it need not touch the executable file
(if it already exists) because the link edit fails. Since both
approaches are historical practice, a conforming application
shall rely on the exit status of fort77, rather than on the
existence or mode of the executable file.
The -g and -s options are not specified as mutually-exclusive.
Historically, these two options have been mutually-exclusive, but
because both are so loosely specified, it seemed appropriate to
leave their interaction unspecified.
The requirement that conforming applications specify compiler
options separately is to reserve the multi-character option name
space for vendor-specific compiler options, which are known to
exist in many historical implementations. Implementations are not
required to recognize, for example, -gc as if it were -g -c; nor
are they forbidden from doing so. The SYNOPSIS shows all of the
options separately to highlight this requirement on applications.
Echoing filenames to standard error is considered a diagnostic
message because it would otherwise be difficult to associate an
error message with the erring file. They are described with
``may'' to allow implementations to use other methods of
identifying files and to parallel the description in c99.
