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