1FORT77(1P) POSIX Programmer's Manual FORT77(1P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 fort77 - FORTRAN compiler (FORTRAN)
13
15 fort77 [-c][-g][-L directory]... [-O optlevel][-o outfile][-s][-w]
16 operand...
17
19 The fort77 utility is the interface to the FORTRAN compilation system;
20 it shall accept the full FORTRAN-77 language defined by the
21 ANSI X3.9-1978 standard. The system conceptually consists of a compiler
22 and link editor. The files referenced by operands are compiled and
23 linked to produce an executable file. It is unspecified whether the
24 linking occurs entirely within the operation of fort77; some implemen‐
25 tations may produce objects that are not fully resolved until the file
26 is executed.
27 If the -c option is present, for all pathname operands of the form file
29 .f, the files:
30 $(basename pathname.f).o
33 shall be created or overwritten as the result of successful compila‐
35 tion. If the -c option is not specified, it is unspecified whether
36 such .o files are created or deleted for the file .f operands.
37 If there are no options that prevent link editing (such as -c) and all
39 operands compile and link without error, the resulting executable file
40 shall be written into the file named by the -o option (if present) or
41 to the file a.out. The executable file shall be created as specified
42 in the System Interfaces volume of IEEE Std 1003.1-2001, except that
43 the file permissions shall be set to:
44 S_IRWXO | S_IRWXG | S_IRWXU
47 and that the bits specified by the umask of the process shall be
49 cleared.
50
52 The fort77 utility shall conform to the Base Definitions volume of
53 IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines, except
54 that:
55 * The -l library operands have the format of options, but their posi‐
57 tion within a list of operands affects the order in which libraries
58 are searched.
59 * The order of specifying the multiple -L options is significant.
61 * Conforming applications shall specify each option separately; that
63 is, grouping option letters (for example, -cg) need not be recog‐
64 nized by all implementations.
65 The following options shall be supported:
67 -c Suppress the link-edit phase of the compilation, and do not
69 remove any object files that are produced.
70 -g Produce symbolic information in the object or executable files;
72 the nature of this information is unspecified, and may be modi‐
73 fied by implementation-defined interactions with other options.
74 -s Produce object or executable files, or both, from which symbolic
76 and other information not required for proper execution using
77 the exec family of functions defined in the System Interfaces
78 volume of IEEE Std 1003.1-2001 has been removed (stripped). If
79 both -g and -s options are present, the action taken is unspeci‐
80 fied.
81 -o outfile
83 Use the pathname outfile, instead of the default a.out, for the
84 executable file produced. If the -o option is present with -c,
85 the result is unspecified.
86 -L directory
88 Change the algorithm of searching for the libraries named in -l
89 operands to look in the directory named by the directory path‐
90 name before looking in the usual places. Directories named in -L
91 options shall be searched in the specified order. At least ten
92 instances of this option shall be supported in a single fort77
93 command invocation. If a directory specified by a -L option con‐
94 tains a file named libf.a, the results are unspecified.
95 -O optlevel
97 Specify the level of code optimization. If the optlevel option-
98 argument is the digit '0', all special code optimizations shall
99 be disabled. If it is the digit '1', the nature of the optimiza‐
100 tion is unspecified. If the -O option is omitted, the nature of
101 the system's default optimization is unspecified. It is unspeci‐
102 fied whether code generated in the presence of the -O 0 option
103 is the same as that generated when -O is omitted. Other optlevel
104 values may be supported.
105 -w Suppress warnings.
107 Multiple instances of -L options can be specified.
110
112 An operand is either in the form of a pathname or the form -l library.
113 At least one operand of the pathname form shall be specified. The fol‐
114 lowing operands shall be supported:
115 file.f The pathname of a FORTRAN source file to be compiled and option‐
117 ally passed to the link editor. The filename operand shall be of
118 this form if the -c option is used.
119 file.a A library of object files typically produced by ar, and passed
121 directly to the link editor. Implementations may recognize
122 implementation-defined suffixes other than .a as denoting object
123 file libraries.
124 file.o An object file produced by fort77 -c and passed directly to the
126 link editor. Implementations may recognize implementation-
127 defined suffixes other than .o as denoting object files.
128 The processing of other files is implementation-defined.
131 -l library
133 (The letter ell.) Search the library named:
134 liblibrary.a
137 A library is searched when its name is encountered, so the placement of
139 a -l operand is significant. Several standard libraries can be speci‐
140 fied in this manner, as described in the EXTENDED DESCRIPTION section.
141 Implementations may recognize implementation-defined suffixes other
142 than .a as denoting libraries.
143
146 Not used.
147
149 The input file shall be one of the following: a text file containing
150 FORTRAN source code; an object file in the format produced by fort77
151 -c; or a library of object files, in the format produced by archiving
152 zero or more object files, using ar. Implementations may supply addi‐
153 tional utilities that produce files in these formats. Additional input
154 files are implementation-defined.
155 A <tab> encountered within the first six characters on a line of source
157 code shall cause the compiler to interpret the following character as
158 if it were the seventh character on the line (that is, in column 7).
159
161 The following environment variables shall affect the execution of
162 fort77:
163 LANG Provide a default value for the internationalization variables
165 that are unset or null. (See the Base Definitions volume of
166 IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
167 ables for the precedence of internationalization variables used
168 to determine the values of locale categories.)
169 LC_ALL If set to a non-empty string value, override the values of all
171 the other internationalization variables.
172 LC_CTYPE
174 Determine the locale for the interpretation of sequences of
175 bytes of text data as characters (for example, single-byte as
176 opposed to multi-byte characters in arguments and input files).
177 LC_MESSAGES
179 Determine the locale that should be used to affect the format
180 and contents of diagnostic messages written to standard error.
181 NLSPATH
183 Determine the location of message catalogs for the processing of
184 LC_MESSAGES .
185 TMPDIR Determine the pathname that should override the default direc‐
187 tory for temporary files, if any.
188
191 Default.
192
194 Not used.
195
197 The standard error shall be used only for diagnostic messages. If more
198 than one file operand ending in .f (or possibly other unspecified suf‐
199 fixes) is given, for each such file:
200 "%s:\n", <file>
203 may be written to allow identification of the diagnostic message with
205 the appropriate input file.
206 This utility may produce warning messages about certain conditions that
208 do not warrant returning an error (non-zero) exit value.
209
211 Object files, listing files, and executable files shall be produced in
212 unspecified formats.
213
215 Standard Libraries
216 The fort77 utility shall recognize the following -l operand for the
217 standard library:
218 -l f This library contains all functions referenced in the
220 ANSI X3.9-1978 standard. This operand shall not be required to
221 be present to cause a search of this library.
222 In the absence of options that inhibit invocation of the link editor,
225 such as -c, the fort77 utility shall cause the equivalent of a -l f op‐
226 erand to be passed to the link editor as the last -l operand, causing
227 it to be searched after all other object files and libraries are
228 loaded.
229 It is unspecified whether the library libf.a exists as a regular file.
231 The implementation may accept as -l operands names of objects that do
232 not exist as regular files.
233 External Symbols
235 The FORTRAN compiler and link editor shall support the significance of
236 external symbols up to a length of at least 31 bytes; case folding is
237 permitted. The action taken upon encountering symbols exceeding the
238 implementation-defined maximum symbol length is unspecified.
239 The compiler and link editor shall support a minimum of 511 external
241 symbols per source or object file, and a minimum of 4095 external sym‐
242 bols total. A diagnostic message is written to standard output if the
243 implementation-defined limit is exceeded; other actions are unspeci‐
244 fied.
245
247 The following exit values shall be returned:
248 0 Successful compilation or link edit.
250 >0 An error occurred.
252
255 When fort77 encounters a compilation error, it shall write a diagnostic
256 to standard error and continue to compile other source code operands.
257 It shall return a non-zero exit status, but it is implementation-
258 defined whether an object module is created. If the link edit is
259 unsuccessful, a diagnostic message shall be written to standard error,
260 and fort77 shall exit with a non-zero status.
261 The following sections are informative.
263
265 None.
266
268 The following usage example compiles xyz.f and creates the executable
269 file foo:
270 fort77 -o foo xyz.f
273 The following example compiles xyz.f and creates the object file xyz.o:
275 fort77 -c xyz.f
278 The following example compiles xyz.f and creates the executable file
280 a.out:
281 fort77 xyz.f
284 The following example compiles xyz.f, links it with b.o, and creates
286 the executable a.out:
287 fort77 xyz.f b.o
290
292 The name of this utility was chosen as fort77 to parallel the renaming
293 of the C compiler. The name f77 was not chosen to avoid problems with
294 historical implementations. The ANSI X3.9-1978 standard was selected as
295 a normative reference because the ISO/IEC version of FORTRAN-77 has
296 been superseded by the ISO/IEC 1539:1990 standard (Fortran-90).
297 The file inclusion and symbol definition #define mechanisms used by the
299 c99 utility were not included in this volume of
300 IEEE Std 1003.1-2001-even though they are commonly implemented-since
301 there is no requirement that the FORTRAN compiler use the C preproces‐
302 sor.
303 The -onetrip option was not included in this volume of
305 IEEE Std 1003.1-2001, even though many historical compilers support it,
306 because it is derived from FORTRAN-66; it is an anachronism that should
307 not be perpetuated.
308 Some implementations produce compilation listings. This aspect of FOR‐
310 TRAN has been left unspecified because there was controversy concerning
311 the various methods proposed for implementing it: a -V option over‐
312 lapped with historical vendor practice and a naming convention of cre‐
313 ating files with .l suffixes collided with historical lex file naming
314 practice.
315 There is no -I option in this version of this volume of
317 IEEE Std 1003.1-2001 to specify a directory for file inclusion. An
318 INCLUDE directive has been a part of the Fortran-90 discussions, but an
319 interface supporting that standard is not in the current scope.
320 It is noted that many FORTRAN compilers produce an object module even
322 when compilation errors occur; during a subsequent compilation, the
323 compiler may patch the object module rather than recompiling all the
324 code. Consequently, it is left to the implementor whether or not an
325 object file is created.
326 A reference to MIL-STD-1753 was removed from an early proposal in
328 response to a request from the POSIX FORTRAN-binding standard develop‐
329 ers. It was not the intention of the standard developers to require
330 certification of the FORTRAN compiler, and IEEE Std 1003.9-1992 does
331 not specify the military standard or any special preprocessing require‐
332 ments. Furthermore, use of that document would have been inappropriate
333 for an international standard.
334 The specification of optimization has been subject to changes through
336 early proposals. At one time, -O and -N were Booleans: optimize and do
337 not optimize (with an unspecified default). Some historical practice
338 led this to be changed to:
339 -O 0 No optimization.
341 -O 1 Some level of optimization.
343 -O n Other, unspecified levels of optimization.
345 It is not always clear whether "good code generation" is the same thing
348 as optimization. Simple optimizations of local actions do not usually
349 affect the semantics of a program. The -O 0 option has been included to
350 accommodate the very particular nature of scientific calculations in a
351 highly optimized environment; compilers make errors. Some degree of
352 optimization is expected, even if it is not documented here, and the
353 ability to shut it off completely could be important when porting an
354 application. An implementation may treat -O 0 as "do less than normal"
355 if it wishes, but this is only meaningful if any of the operations it
356 performs can affect the semantics of a program. It is highly dependent
357 on the implementation whether doing less than normal is logical. It is
358 not the intent of the -O 0 option to ask for inefficient code genera‐
359 tion, but rather to assure that any semantically visible optimization
360 is suppressed.
361 The specification of standard library access is consistent with the C
363 compiler specification. Implementations are not required to have
364 /usr/lib/libf.a, as many historical implementations do, but if not they
365 are required to recognize f as a token.
366 External symbol size limits are in normative text; conforming applica‐
368 tions need to know these limits. However, the minimum maximum symbol
369 length should be taken as a constraint on a conforming application, not
370 on an implementation, and consequently the action taken for a symbol
371 exceeding the limit is unspecified. The minimum size for the external
372 symbol table was added for similar reasons.
373 The CONSEQUENCES OF ERRORS section clearly specifies the behavior of
375 the compiler when compilation or link-edit errors occur. The behavior
376 of several historical implementations was examined, and the choice was
377 made to be silent on the status of the executable, or a.out, file in
378 the face of compiler or linker errors. If a linker writes the exe‐
379 cutable file, then links it on disk with lseek()s and write()s, the
380 partially linked executable file can be left on disk and its execute
381 bits turned off if the link edit fails. However, if the linker links
382 the image in memory before writing the file to disk, it need not touch
383 the executable file (if it already exists) because the link edit fails.
384 Since both approaches are historical practice, a conforming application
385 shall rely on the exit status of fort77, rather than on the existence
386 or mode of the executable file.
387 The -g and -s options are not specified as mutually-exclusive. Histor‐
389 ically these two options have been mutually-exclusive, but because both
390 are so loosely specified, it seemed appropriate to leave their interac‐
391 tion unspecified.
392 The requirement that conforming applications specify compiler options
394 separately is to reserve the multi-character option name space for ven‐
395 dor-specific compiler options, which are known to exist in many histor‐
396 ical implementations. Implementations are not required to recognize,
397 for example, -gc as if it were -g -c; nor are they forbidden from doing
398 so. The SYNOPSIS shows all of the options separately to highlight this
399 requirement on applications.
400 Echoing filenames to standard error is considered a diagnostic message
402 because it would otherwise be difficult to associate an error message
403 with the erring file. They are described with "may" to allow implemen‐
404 tations to use other methods of identifying files and to parallel the
405 description in c99.
406
408 A compilation system based on the ISO/IEC 1539:1990 standard (For‐
409 tran-90) may be considered for a future version; it may have a differ‐
410 ent utility name from fort77.
411
413 ar, asa, c99, umask(), the System Interfaces volume of
414 IEEE Std 1003.1-2001, exec
415
417 Portions of this text are reprinted and reproduced in electronic form
418 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
419 -- Portable Operating System Interface (POSIX), The Open Group Base
420 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
421 Electrical and Electronics Engineers, Inc and The Open Group. In the
422 event of any discrepancy between this version and the original IEEE and
423 The Open Group Standard, the original IEEE and The Open Group Standard
424 is the referee document. The original Standard can be obtained online
425 at http://www.opengroup.org/unix/online.html .
426IEEE/The Open Group 2003 FORT77(1P)