FreeBSD Manual Pages
G77(1) GNU G77(1) N g77 - GNU project Fortran 77 compiler S g77 [--cc|--SS|--EE] [--gg] [--ppgg] [--OOlevel] [--WWwarn...] [--ppeeddaannttiicc] [--IIdir...] [--LLdir...] [--DDmacro[=defn]...] [--UUmacro] [--ffoption...] [--mmmachine-option...] [--oo outfile] infile... Only the most useful options are listed here; see below for the remain- der. D The gg7777 command supports all the options supported by the ggcccc command. All ggcccc and gg7777 options are accepted both by gg7777 and by ggcccc (as well as any other drivers built at the same time, such as gg++++), since adding gg7777 to the ggcccc distribution enables acceptance of gg7777 options by all of the relevant drivers. In some cases, options have positive and negative forms; the negative form of --ffffoooo would be --ffnnoo--ffoooo. This manual documents only one of these two forms, whichever one is not the default. O Here is a summary of all the options specific to GNU Fortran, grouped by type. Explanations are in the following sections. Overall Options --ffvveerrssiioonn --ffsseett--gg7777--ddeeffaauullttss --ffnnoo--ssiilleenntt Shorthand Options --ffff6666 --ffnnoo--ff6666 --ffff7777 --ffnnoo--ff7777 --ffnnoo--uuggllyy Fortran Language Options --ffffrreeee--ffoorrmm --ffnnoo--ffiixxeedd--ffoorrmm --ffff9900 --ffvvxxtt --ffddoollllaarr--ookk --ffnnoo--bbaacckk-- ssllaasshh --ffnnoo--uuggllyy--aarrggss --ffnnoo--uuggllyy--aassssiiggnn --ffnnoo--uuggllyy--aassssuummeedd --ffuuggllyy-- ccoommmmaa --ffuuggllyy--ccoommpplleexx --ffuuggllyy--iinniitt --ffuuggllyy--llooggiinntt --ffoonneettrriipp --ffttyyppeelleessss--bboozz --ffiinnttrriinn--ccaassee--iinniittccaapp --ffiinnttrriinn--ccaassee--uuppppeerr --ffiinnttrriinn-- ccaassee--lloowweerr --ffiinnttrriinn--ccaassee--aannyy --ffmmaattcchh--ccaassee--iinniittccaapp --ffmmaattcchh--ccaassee-- uuppppeerr --ffmmaattcchh--ccaassee--lloowweerr --ffmmaattcchh--ccaassee--aannyy --ffssoouurrccee--ccaassee--uuppppeerr --ffssoouurrccee--ccaassee--lloowweerr --ffssoouurrccee--ccaassee--pprreesseerrvvee --ffssyymmbbooll--ccaassee--iinniittccaapp --ffssyymmbbooll--ccaassee--uuppppeerr --ffssyymmbbooll--ccaassee--lloowweerr --ffssyymmbbooll--ccaassee--aannyy --ffccaassee-- ssttrriicctt--uuppppeerr --ffccaassee--ssttrriicctt--lloowweerr --ffccaassee--iinniittccaapp --ffccaassee--uuppppeerr --ffccaassee--lloowweerr --ffccaassee--pprreesseerrvvee --ffff22cc--iinnttrriinnssiiccss--ddeelleettee --ffff22cc--iinn-- ttrriinnssiiccss--hhiiddee --ffff22cc--iinnttrriinnssiiccss--ddiissaabbllee --ffff22cc--iinnttrriinnssiiccss--eennaabbllee --ffbbaadduu7777--iinnttrriinnssiiccss--ddeelleettee --ffbbaadduu7777--iinnttrriinnssiiccss--hhiiddee --ffbbaadduu7777--iinn-- ttrriinnssiiccss--ddiissaabbllee --ffbbaadduu7777--iinnttrriinnssiiccss--eennaabbllee --ffff9900--iinnttrriinnssiiccss-- ddeelleettee --ffff9900--iinnttrriinnssiiccss--hhiiddee --ffff9900--iinnttrriinnssiiccss--ddiissaabbllee --ffff9900--iinn-- ttrriinnssiiccss--eennaabbllee --ffggnnuu--iinnttrriinnssiiccss--ddeelleettee --ffggnnuu--iinnttrriinnssiiccss--hhiiddee --ffggnnuu--iinnttrriinnssiiccss--ddiissaabbllee --ffggnnuu--iinnttrriinnssiiccss--eennaabbllee --ffmmiill--iinnttrriinnssiiccss-- ddeelleettee --ffmmiill--iinnttrriinnssiiccss--hhiiddee --ffmmiill--iinnttrriinnssiiccss--ddiissaabbllee --ffmmiill--iinn-- ttrriinnssiiccss--eennaabbllee --ffuunniixx--iinnttrriinnssiiccss--ddeelleettee --ffuunniixx--iinnttrriinnssiiccss--hhiiddee --ffuunniixx--iinnttrriinnssiiccss--ddiissaabbllee --ffuunniixx--iinnttrriinnssiiccss--eennaabbllee --ffvvxxtt--iinnttrriinn-- ssiiccss--ddeelleettee --ffvvxxtt--iinnttrriinnssiiccss--hhiiddee --ffvvxxtt--iinnttrriinnssiiccss--ddiissaabbllee --ffvvxxtt-- iinnttrriinnssiiccss--eennaabbllee --ffffiixxeedd--lliinnee--lleennggtthh--n --ffffiixxeedd--lliinnee--lleennggtthh--nnoonnee Warning Options --ffssyynnttaaxx--oonnllyy --ppeeddaannttiicc --ppeeddaannttiicc--eerrrroorrss --ffppeeddaannttiicc --ww --WWnnoo-- gglloobbaallss --WWiimmpplliicciitt --WWuunnuusseedd --WWuunniinniittiiaalliizzeedd --WWaallll --WWssuurrpprriissiinngg --WWeerrrroorr --WW Debugging Options --gg Optimization Options --mmaalliiggnn--ddoouubbllee --ffffllooaatt--ssttoorree --ffffoorrccee--mmeemm --ffffoorrccee--aaddddrr --ffnnoo--iinn-- lliinnee --ffffaasstt--mmaatthh --ffssttrreennggtthh--rreedduuccee --ffrreerruunn--ccssee--aafftteerr--lloooopp --ffuunn-- ssaaffee--mmaatthh--ooppttiimmiizzaattiioonnss --ffnnoo--ttrraappppiinngg--mmaatthh --ffeexxppeennssiivvee--ooppttiimmiizzaa-- ttiioonnss --ffddeellaayyeedd--bbrraanncchh --ffsscchheedduullee--iinnssnnss --ffsscchheedduullee--iinnssnn22 --ffccaalllleerr--ssaavveess --ffuunnrroollll--llooooppss --ffuunnrroollll--aallll--llooooppss --ffnnoo--mmoovvee--aallll-- mmoovvaabblleess --ffnnoo--rreedduuccee--aallll--ggiivvss --ffnnoo--rreerruunn--lloooopp--oopptt Directory Options --IIdir --II-- Code Generation Options --ffnnoo--aauuttoommaattiicc --ffiinniitt--llooccaall--zzeerroo --ffnnoo--ff22cc --ffff22cc--lliibbrraarryy --ffnnoo--uunn-- ddeerrssccoorriinngg --ffnnoo--iiddeenntt --ffppcccc--ssttrruucctt--rreettuurrnn --ffrreegg--ssttrruucctt--rreettuurrnn --ffsshhoorrtt--ddoouubbllee --ffnnoo--ccoommmmoonn --ffppaacckk--ssttrruucctt --ffzzeerrooss --ffnnoo--sseeccoonndd--uunn-- ddeerrssccoorree --ffeemmuullaattee--ccoommpplleexx --ffaalliiaass--cchheecckk --ffaarrgguummeenntt--aalliiaass --ffaarrgguu-- mmeenntt--nnooaalliiaass --ffnnoo--aarrgguummeenntt--nnooaalliiaass--gglloobbaall --ffnnoo--gglloobbaallss --ffffllaatttteenn-- aarrrraayyss --ffbboouunnddss--cchheecckk --ffffoorrttrraann--bboouunnddss--cchheecckk Compilation can involve as many as four stages: preprocessing, code generation (often what is really meant by the term ``compilation''), assembly, and linking, always in that order. The first three stages apply to an individual source file, and end by producing an object file; linking combines all the object files (those newly compiled, and those specified as input) into an executable file. For any given input file, the file name suffix determines what kind of program is contained in the file---that is, the language in which the program is written is generally indicated by the suffix. Suffixes spe- cific to GNU Fortran are listed below. file..ff file..ffoorr file..FFOORR Fortran source code that should not be preprocessed. Such source code cannot contain any preprocessor directives, such as "#include", "#define", "#if", and so on. You can force ..ff files to be preprocessed by ccpppp by using --xx ff7777--ccpppp--iinnppuutt. file..FF file..ffpppp file..FFPPPP Fortran source code that must be preprocessed (by the C preproces- sor ccpppp, which is part of GNU CC). Note that preprocessing is not extended to the contents of files included by the "INCLUDE" directive---the "#include" preprocessor directive must be used instead. file..rr Ratfor source code, which must be preprocessed by the rraattffoorr com- mand, which is available separately (as it is not yet part of the GNU Fortran distribution). One version in Fortran, adapted for use with gg7777 is at <ffttpp::////mmeemmbbeerrss..aaooll..ccoomm//nn88ttmm//rraatt77..uuuuee> (of uncertain copyright status). Another, public domain version in C is at <hhttttpp::////sseeppwwwwww..ssttaannffoorrdd..eedduu//sseepp//pprrooff//rraattffoorr..sshhaarr..22>. UNIX users typically use the file.f and file.F nomenclature. Users of other operating systems, especially those that cannot distinguish up- per-case letters from lower-case letters in their file names, typically use the file.for and file.fpp nomenclature. Use of the preprocessor ccpppp allows use of C-like constructs such as "#define" and "#include", but can lead to unexpected, even mistaken, results due to Fortran's source file format. It is recommended that use of the C preprocessor be limited to "#include" and, in conjunction with "#define", only "#if" and related directives, thus avoiding in- line macro expansion entirely. This recommendation applies especially when using the traditional fixed source form. With free source form, fewer unexpected transformations are likely to happen, but use of con- structs such as Hollerith and character constants can nevertheless present problems, especially when these are continued across multiple source lines. These problems result, primarily, from differences be- tween the way such constants are interpreted by the C preprocessor and by a Fortran compiler. Another example of a problem that results from using the C preprocessor is that a Fortran comment line that happens to contain any characters ``interesting'' to the C preprocessor, such as a backslash at the end of the line, is not recognized by the preprocessor as a comment line, so instead of being passed through ``raw'', the line is edited accord- ing to the rules for the preprocessor. For example, the backslash at the end of the line is removed, along with the subsequent newline, re- sulting in the next line being effectively commented out---unfortunate if that line is a non-comment line of important code! Note: The --ttrraaddiittiioonnaall and --uunnddeeff flags are supplied to ccpppp by default, to help avoid unpleasant surprises. This means that ANSI C preprocessor features (such as the ## operator) aren't available, and only variables in the C reserved namespace (gen- erally, names with a leading underscore) are liable to substitution by C predefines. Thus, if you want to do system-specific tests, use, for example, ##iiffddeeff __lliinnuuxx__ rather than ##iiffddeeff lliinnuuxx. Use the --vv option to see exactly how the preprocessor is invoked. Unfortunately, the --ttrraaddiittiioonnaall flag will not avoid an error from any- thing that ccpppp sees as an unterminated C comment, such as: C Some Fortran compilers accept /* as starting C an inline comment. The following options that affect overall processing are recognized by the gg7777 and ggcccc commands in a GNU Fortran installation: --ffvveerrssiioonn Ensure that the gg7777 version of the compiler phase is reported, if run, and, starting in "egcs" version 1.1, that internal consistency checks in the f771 program are run. This option is supplied automatically when --vv or ----vveerrbboossee is spec- ified as a command-line option for gg7777 or ggcccc and when the result- ing commands compile Fortran source files. In GCC 3.1, this is changed back to the behaviour ggcccc displays for ..cc files. --ffsseett--gg7777--ddeeffaauullttss Version info: This option was obsolete as of "egcs" version 1.1. The effect is instead achieved by the "lang_init_options" routine in gcc/gcc/f/com.c. Set up whatever ggcccc options are to apply to Fortran compilations, and avoid running internal consistency checks that might take some time. This option is supplied automatically when compiling Fortran code via the gg7777 or ggcccc command. The description of this option is pro- vided so that users seeing it in the output of, say, gg7777 --vv under- stand why it is there. Also, developers who run "f771" directly might want to specify it by hand to get the same defaults as they would running "f771" via gg7777 or ggcccc However, such developers should, after linking a new "f771" executable, invoke it without this option once, e.g. via "./f771 -quiet < /dev/null", to ensure that they have not intro- duced any internal inconsistencies (such as in the table of intrin- sics) before proceeding---gg7777 will crash with a diagnostic if it detects an inconsistency. --ffnnoo--ssiilleenntt Print (to "stderr") the names of the program units as they are com- piled, in a form similar to that used by popular UNIX ff7777 implemen- tations and ff22cc SShhoorrtthhaanndd OOppttiioonnss The following options serve as ``shorthand'' for other options accepted by the compiler: --ffuuggllyy Note: This option is no longer supported. The information, below, is provided to aid in the conversion of old scripts. Specify that certain ``ugly'' constructs are to be quietly ac- cepted. Same as: -fugly-args -fugly-assign -fugly-assumed -fugly-comma -fugly-complex -fugly-init -fugly-logint These constructs are considered inappropriate to use in new or well-maintained portable Fortran code, but widely used in old code. --ffnnoo--uuggllyy Specify that all ``ugly'' constructs are to be noisily rejected. Same as: -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed -fno-ugly-comma -fno-ugly-complex -fno-ugly-init -fno-ugly-logint --ffff6666 Specify that the program is written in idiomatic FORTRAN 66. Same as --ffoonneettrriipp --ffuuggllyy--aassssuummeedd. The --ffnnoo--ff6666 option is the inverse of --ffff6666. As such, it is the same as --ffnnoo--oonneettrriipp --ffnnoo--uuggllyy--aassssuummeedd. The meaning of this option is likely to be refined as future ver- sions of gg7777 provide more compatibility with other existing and ob- solete Fortran implementations. --ffff7777 Specify that the program is written in idiomatic UNIX FORTRAN 77 and/or the dialect accepted by the ff22cc product. Same as --ffbbaacckk-- ssllaasshh --ffnnoo--ttyyppeelleessss--bboozz. The meaning of this option is likely to be refined as future ver- sions of gg7777 provide more compatibility with other existing and ob- solete Fortran implementations. --ffnnoo--ff7777 The --ffnnoo--ff7777 option is not the inverse of --ffff7777. It specifies that the program is not written in idiomatic UNIX FORTRAN 77 or ff22cc but in a more widely portable dialect. --ffnnoo--ff7777 is the same as --ffnnoo-- bbaacckkssllaasshh. The meaning of this option is likely to be refined as future ver- sions of gg7777 provide more compatibility with other existing and ob- solete Fortran implementations. OOppttiioonnss CCoonnttrroolllliinngg FFoorrttrraann DDiiaalleecctt The following options control the dialect of Fortran that the compiler accepts: --ffffrreeee--ffoorrmm --ffnnoo--ffiixxeedd--ffoorrmm Specify that the source file is written in free form (introduced in Fortran 90) instead of the more-traditional fixed form. --ffff9900 Allow certain Fortran-90 constructs. This option controls whether certain Fortran 90 constructs are rec- ognized. (Other Fortran 90 constructs might or might not be recog- nized depending on other options such as --ffvvxxtt, --ffff9900--iinnttrriinnssiiccss-- eennaabbllee, and the current level of support for Fortran 90.) --ffvvxxtt Specify the treatment of certain constructs that have different meanings depending on whether the code is written in GNU Fortran (based on FORTRAN 77 and akin to Fortran 90) or VXT Fortran (more like VAX FORTRAN). The default is --ffnnoo--vvxxtt. --ffvvxxtt specifies that the VXT Fortran in- terpretations for those constructs are to be chosen. --ffddoollllaarr--ookk Allow $$ as a valid character in a symbol name. --ffnnoo--bbaacckkssllaasshh Specify that \\ is not to be specially interpreted in character and Hollerith constants a la C and many UNIX Fortran compilers. For example, with --ffbbaacckkssllaasshh in effect, AA\\nnBB specifies three char- acters, with the second one being newline. With --ffnnoo--bbaacckkssllaasshh, it specifies four characters, AA, \\, nn, and BB. Note that gg7777 implements a fairly general form of backslash pro- cessing that is incompatible with the narrower forms supported by some other compilers. For example, ''AA\\000033BB'' is a three-character string in gg7777 whereas other compilers that support backslash might not support the three-octal-digit form, and thus treat that string as longer than three characters. --ffnnoo--uuggllyy--aarrggss Disallow passing Hollerith and typeless constants as actual argu- ments (for example, CCAALLLL FFOOOO((44HHAABBCCDD))). --ffuuggllyy--aassssiiggnn Use the same storage for a given variable regardless of whether it is used to hold an assigned-statement label (as in AASSSSIIGGNN 1100 TTOO II) or used to hold numeric data (as in II == 33). --ffuuggllyy--aassssuummeedd Assume any dummy array with a final dimension specified as 11 is re- ally an assumed-size array, as if ** had been specified for the fi- nal dimension instead of 11. For example, DDIIMMEENNSSIIOONN XX((11)) is treated as if it had read DDIIMMEENNSSIIOONN XX((**)). --ffuuggllyy--ccoommmmaa In an external-procedure invocation, treat a trailing comma in the argument list as specification of a trailing null argument, and treat an empty argument list as specification of a single null ar- gument. For example, CCAALLLL FOO((,,)) is treated as CCAALLLL FFOOOO((%%VAL((00)),, %%VAL((00)))). That is, two null arguments are specified by the procedure call when --ffuuggllyy--ccoommmmaa is in force. And FF == FUNC() is treated as FF == FFUUNNCC((%%VAL((00)))). The default behavior, --ffnnoo--uuggllyy--ccoommmmaa, is to ignore a single trail- ing comma in an argument list. So, by default, CCAALLLL FFOOOO((XX,,)) is treated exactly the same as CCAALLLL FOO((XX)). --ffuuggllyy--ccoommpplleexx Do not complain about RREEAALL((expr)) or AAIIMMAAGG((expr)) when expr is a "COMPLEX" type other than "COMPLEX(KIND=1)"---usually this is used to permit "COMPLEX(KIND=2)" ("DOUBLE COMPLEX") operands. The --ffff9900 option controls the interpretation of this construct. --ffnnoo--uuggllyy--iinniitt Disallow use of Hollerith and typeless constants as initial values (in "PARAMETER" and "DATA" statements), and use of character con- stants to initialize numeric types and vice versa. For example, DDAATTAA II//''FF''//,, CCHHRRVVAARR//6655//,, JJ//44HHAABBCCDD// is disallowed by --ffnnoo--uuggllyy--iinniitt. --ffuuggllyy--llooggiinntt Treat "INTEGER" and "LOGICAL" variables and expressions as poten- tial stand-ins for each other. For example, automatic conversion between "INTEGER" and "LOGICAL" is enabled, for many contexts, via this option. --ffoonneettrriipp Executable iterative "DO" loops are to be executed at least once each time they are reached. ANSI FORTRAN 77 and more recent versions of the Fortran standard specify that the body of an iterative "DO" loop is not executed if the number of iterations calculated from the parameters of the loop is less than 1. (For example, DDOO 1100 II == 11,, 00.) Such a loop is called a zero-trip loop. Prior to ANSI FORTRAN 77, many compilers implemented "DO" loops such that the body of a loop would be executed at least once, even if the iteration count was zero. Fortran code written assuming this behavior is said to require one-trip loops. For example, some code written to the FORTRAN 66 standard expects this behavior from its "DO" loops, although that standard did not specify this behav- ior. The --ffoonneettrriipp option specifies that the source file(s) being com- piled require one-trip loops. This option affects only those loops specified by the (iterative) "DO" statement and by implied-"DO" lists in I/O statements. Loops specified by implied-"DO" lists in "DATA" and specification (non- executable) statements are not affected. --ffttyyppeelleessss--bboozz Specifies that prefix-radix non-decimal constants, such as ZZ''AABBCCDD'', are typeless instead of "INTEGER(KIND=1)". You can test for yourself whether a particular compiler treats the prefix form as "INTEGER(KIND=1)" or typeless by running the follow- ing program: EQUIVALENCE (I, R) R = Z'ABCD1234' J = Z'ABCD1234' IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS' IF (J .NE. I) PRINT *, 'Prefix form is INTEGER' END Reports indicate that many compilers process this form as "INTE- GER(KIND=1)", though a few as typeless, and at least one based on a command-line option specifying some kind of compatibility. --ffiinnttrriinn--ccaassee--iinniittccaapp --ffiinnttrriinn--ccaassee--uuppppeerr --ffiinnttrriinn--ccaassee--lloowweerr --ffiinnttrriinn--ccaassee--aannyy Specify expected case for intrinsic names. --ffiinnttrriinn--ccaassee--lloowweerr is the default. --ffmmaattcchh--ccaassee--iinniittccaapp --ffmmaattcchh--ccaassee--uuppppeerr --ffmmaattcchh--ccaassee--lloowweerr --ffmmaattcchh--ccaassee--aannyy Specify expected case for keywords. --ffmmaattcchh--ccaassee--lloowweerr is the de- fault. --ffssoouurrccee--ccaassee--uuppppeerr --ffssoouurrccee--ccaassee--lloowweerr --ffssoouurrccee--ccaassee--pprreesseerrvvee Specify whether source text other than character and Hollerith con- stants is to be translated to uppercase, to lowercase, or preserved as is. --ffssoouurrccee--ccaassee--lloowweerr is the default. --ffssyymmbbooll--ccaassee--iinniittccaapp --ffssyymmbbooll--ccaassee--uuppppeerr --ffssyymmbbooll--ccaassee--lloowweerr --ffssyymmbbooll--ccaassee--aannyy Specify valid cases for user-defined symbol names. --ffssyymmbbooll--ccaassee-- aannyy is the default. --ffccaassee--ssttrriicctt--uuppppeerr Same as --ffiinnttrriinn--ccaassee--uuppppeerr --ffmmaattcchh--ccaassee--uuppppeerr --ffssoouurrccee--ccaassee--pprree-- sseerrvvee --ffssyymmbbooll--ccaassee--uuppppeerr. (Requires all pertinent source to be in uppercase.) --ffccaassee--ssttrriicctt--lloowweerr Same as --ffiinnttrriinn--ccaassee--lloowweerr --ffmmaattcchh--ccaassee--lloowweerr --ffssoouurrccee--ccaassee--pprree-- sseerrvvee --ffssyymmbbooll--ccaassee--lloowweerr. (Requires all pertinent source to be in lowercase.) --ffccaassee--iinniittccaapp Same as --ffiinnttrriinn--ccaassee--iinniittccaapp --ffmmaattcchh--ccaassee--iinniittccaapp --ffssoouurrccee--ccaassee-- pprreesseerrvvee --ffssyymmbbooll--ccaassee--iinniittccaapp. (Requires all pertinent source to be in initial capitals, as in PPrriinntt **,,SSqqRRtt((VVaalluuee)).) --ffccaassee--uuppppeerr Same as --ffiinnttrriinn--ccaassee--aannyy --ffmmaattcchh--ccaassee--aannyy --ffssoouurrccee--ccaassee--uuppppeerr --ffssyymmbbooll--ccaassee--aannyy. (Maps all pertinent source to uppercase.) --ffccaassee--lloowweerr Same as --ffiinnttrriinn--ccaassee--aannyy --ffmmaattcchh--ccaassee--aannyy --ffssoouurrccee--ccaassee--lloowweerr --ffssyymmbbooll--ccaassee--aannyy. (Maps all pertinent source to lowercase.) --ffccaassee--pprreesseerrvvee Same as --ffiinnttrriinn--ccaassee--aannyy --ffmmaattcchh--ccaassee--aannyy --ffssoouurrccee--ccaassee--pprreesseerrvvee --ffssyymmbbooll--ccaassee--aannyy. (Preserves all case in user-defined symbols, while allowing any-case matching of intrinsics and keywords. For example, ccaallll FFoooo((ii,,II)) would pass two different variables named ii and II to a procedure named FFoooo.) --ffbbaadduu7777--iinnttrriinnssiiccss--ddeelleettee --ffbbaadduu7777--iinnttrriinnssiiccss--hhiiddee --ffbbaadduu7777--iinnttrriinnssiiccss--ddiissaabbllee --ffbbaadduu7777--iinnttrriinnssiiccss--eennaabbllee Specify status of UNIX intrinsics having inappropriate forms. --ffbbaadduu7777--iinnttrriinnssiiccss--eennaabbllee is the default. --ffff22cc--iinnttrriinnssiiccss--ddeelleettee --ffff22cc--iinnttrriinnssiiccss--hhiiddee --ffff22cc--iinnttrriinnssiiccss--ddiissaabbllee --ffff22cc--iinnttrriinnssiiccss--eennaabbllee Specify status of f2c-specific intrinsics. --ffff22cc--iinnttrriinnssiiccss--eennaabbllee is the default. --ffff9900--iinnttrriinnssiiccss--ddeelleettee --ffff9900--iinnttrriinnssiiccss--hhiiddee --ffff9900--iinnttrriinnssiiccss--ddiissaabbllee --ffff9900--iinnttrriinnssiiccss--eennaabbllee Specify status of F90-specific intrinsics. --ffff9900--iinnttrriinnssiiccss--eennaabbllee is the default. --ffggnnuu--iinnttrriinnssiiccss--ddeelleettee --ffggnnuu--iinnttrriinnssiiccss--hhiiddee --ffggnnuu--iinnttrriinnssiiccss--ddiissaabbllee --ffggnnuu--iinnttrriinnssiiccss--eennaabbllee Specify status of Digital's COMPLEX-related intrinsics. --ffggnnuu--iinn-- ttrriinnssiiccss--eennaabbllee is the default. --ffmmiill--iinnttrriinnssiiccss--ddeelleettee --ffmmiill--iinnttrriinnssiiccss--hhiiddee --ffmmiill--iinnttrriinnssiiccss--ddiissaabbllee --ffmmiill--iinnttrriinnssiiccss--eennaabbllee Specify status of MIL-STD-1753-specific intrinsics. --ffmmiill--iinnttrriinn-- ssiiccss--eennaabbllee is the default. --ffuunniixx--iinnttrriinnssiiccss--ddeelleettee --ffuunniixx--iinnttrriinnssiiccss--hhiiddee --ffuunniixx--iinnttrriinnssiiccss--ddiissaabbllee --ffuunniixx--iinnttrriinnssiiccss--eennaabbllee Specify status of UNIX intrinsics. --ffuunniixx--iinnttrriinnssiiccss--eennaabbllee is the default. --ffvvxxtt--iinnttrriinnssiiccss--ddeelleettee --ffvvxxtt--iinnttrriinnssiiccss--hhiiddee --ffvvxxtt--iinnttrriinnssiiccss--ddiissaabbllee --ffvvxxtt--iinnttrriinnssiiccss--eennaabbllee Specify status of VXT intrinsics. --ffvvxxtt--iinnttrriinnssiiccss--eennaabbllee is the default. --ffffiixxeedd--lliinnee--lleennggtthh--n Set column after which characters are ignored in typical fixed-form lines in the source file, and through which spaces are assumed (as if padded to that length) after the ends of short fixed-form lines. Popular values for n include 72 (the standard and the default), 80 (card image), and 132 (corresponds to ``extended-source'' options in some popular compilers). n may be nnoonnee, meaning that the entire line is meaningful and that continued character constants never have implicit spaces appended to them to fill out the line. --ffffiixxeedd--lliinnee--lleennggtthh--00 means the same thing as --ffffiixxeedd--lliinnee--lleennggtthh-- nnoonnee. OOppttiioonnss ttoo RReeqquueesstt oorr SSuupppprreessss WWaarrnniinnggss Warnings are diagnostic messages that report constructions which are not inherently erroneous but which are risky or suggest there might have been an error. You can request many specific warnings with options beginning --WW, for example --WWiimmpplliicciitt to request warnings on implicit declarations. Each of these specific warning options also has a negative form beginning --WWnnoo-- to turn off warnings; for example, --WWnnoo--iimmpplliicciitt. This manual lists only one of the two forms, whichever is not the default. These options control the amount and kinds of warnings produced by GNU Fortran: --ffssyynnttaaxx--oonnllyy Check the code for syntax errors, but don't do anything beyond that. --ppeeddaannttiicc Issue warnings for uses of extensions to ANSI FORTRAN 77. --ppeeddaann-- ttiicc also applies to C-language constructs where they occur in GNU Fortran source files, such as use of \\ee in a character constant within a directive like ##iinncclluuddee. Valid ANSI FORTRAN 77 programs should compile properly with or without this option. However, without this option, certain GNU ex- tensions and traditional Fortran features are supported as well. With this option, many of them are rejected. Some users try to use --ppeeddaannttiicc to check programs for strict ANSI conformance. They soon find that it does not do quite what they want---it finds some non-ANSI practices, but not all. However, im- provements to gg7777 in this area are welcome. --ppeeddaannttiicc--eerrrroorrss Like --ppeeddaannttiicc, except that errors are produced rather than warn- ings. --ffppeeddaannttiicc Like --ppeeddaannttiicc, but applies only to Fortran constructs. --ww Inhibit all warning messages. --WWnnoo--gglloobbaallss Inhibit warnings about use of a name as both a global name (a sub- routine, function, or block data program unit, or a common block) and implicitly as the name of an intrinsic in a source file. Also inhibit warnings about inconsistent invocations and/or defini- tions of global procedures (function and subroutines). Such incon- sistencies include different numbers of arguments and different types of arguments. --WWiimmpplliicciitt Warn whenever a variable, array, or function is implicitly de- clared. Has an effect similar to using the "IMPLICIT NONE" state- ment in every program unit. (Some Fortran compilers provide this feature by an option named --uu or //WWAARRNNIINNGGSS==DDEECCLLAARRAATTIIOONNSS.) --WWuunnuusseedd Warn whenever a variable is unused aside from its declaration. --WWuunniinniittiiaalliizzeedd Warn whenever an automatic variable is used without first being initialized. These warnings are possible only in optimizing compilation, because they require data-flow information that is computed only when opti- mizing. If you don't specify --OO, you simply won't get these warn- ings. These warnings occur only for variables that are candidates for register allocation. Therefore, they do not occur for a variable whose address is taken, or whose size is other than 1, 2, 4 or 8 bytes. Also, they do not occur for arrays, even when they are in registers. Note that there might be no warning about a variable that is used only to compute a value that itself is never used, because such computations may be deleted by data-flow analysis before the warn- ings are printed. These warnings are made optional because GNU Fortran is not smart enough to see all the reasons why the code might be correct despite appearing to have an error. Here is one example of how this can happen: SUBROUTINE DISPAT(J) IF (J.EQ.1) I=1 IF (J.EQ.2) I=4 IF (J.EQ.3) I=5 CALL FOO(I) END If the value of "J" is always 1, 2 or 3, then "I" is always ini- tialized, but GNU Fortran doesn't know this. Here is another com- mon case: SUBROUTINE MAYBE(FLAG) LOGICAL FLAG IF (FLAG) VALUE = 9.4 ... IF (FLAG) PRINT *, VALUE END This has no bug because "VALUE" is used only if it is set. --WWaallll The --WWuunnuusseedd and --WWuunniinniittiiaalliizzeedd options combined. These are all the options which pertain to usage that we recommend avoiding and that we believe is easy to avoid. (As more warnings are added to gg7777 some might be added to the list enabled by --WWaallll.) The remaining --WW...... options are not implied by --WWaallll because they warn about constructions that we consider reasonable to use, on occasion, in clean programs. --WWssuurrpprriissiinngg Warn about ``suspicious'' constructs that are interpreted by the compiler in a way that might well be surprising to someone reading the code. These differences can result in subtle, compiler-depen- dent (even machine-dependent) behavioral differences. The con- structs warned about include: o Expressions having two arithmetic operators in a row, such as XX**--YY. Such a construct is nonstandard, and can produce unex- pected results in more complicated situations such as XX****--YY**ZZ. gg7777 along with many other compilers, interprets this example differently than many programmers, and a few other compilers. Specifically, gg7777 interprets XX****--YY**ZZ as ((XX****((--YY))))**ZZ, while oth- ers might think it should be interpreted as XX****((--((YY**ZZ)))). A revealing example is the constant expression 22****--22**11.., which gg7777 evaluates to .25, while others might evaluate it to 0., the difference resulting from the way precedence affects type pro- motion. (The --ffppeeddaannttiicc option also warns about expressions having two arithmetic operators in a row.) o Expressions with a unary minus followed by an operand and then a binary operator other than plus or minus. For example, --22****22 produces a warning, because the precedence is --((22****22)), yielding -4, not ((--22))****22, which yields 4, and which might represent what a programmer expects. An example of an expression producing different results in a surprising way is --II**SS, where I holds the value --22114477448833664488 and S holds 00..55. On many systems, negating I results in the same value, not a positive number, because it is already the lower bound of what an "INTEGER(KIND=1)" variable can hold. So, the expression evaluates to a positive number, while the ``ex- pected'' interpretation, ((--II))**SS, would evaluate to a negative number. Even cases such as --II**JJ produce warnings, even though, in most configurations and situations, there is no computational dif- ference between the results of the two interpretations---the purpose of this warning is to warn about differing interpreta- tions and encourage a better style of coding, not to identify only those places where bugs might exist in the user's code. o "DO" loops with "DO" variables that are not of integral type---that is, using "REAL" variables as loop control vari- ables. Although such loops can be written to work in the ``ob- vious'' way, the way gg7777 is required by the Fortran standard to interpret such code is likely to be quite different from the way many programmers expect. (This is true of all "DO" loops, but the differences are pronounced for non-integral loop con- trol variables.) --WWeerrrroorr Make all warnings into errors. --WW Turns on ``extra warnings'' and, if optimization is specified via --OO, the --WWuunniinniittiiaalliizzeedd option. (This might change in future ver- sions of gg7777 ``Extra warnings'' are issued for: o Unused parameters to a procedure (when --WWuunnuusseedd also is speci- fied). o Overflows involving floating-point constants (not available for certain configurations). Some of these have no effect when compiling programs written in For- tran: --WWccoommmmeenntt --WWffoorrmmaatt --WWppaarreenntthheesseess --WWsswwiittcchh --WWttrraaddiittiioonnaall --WWsshhaaddooww --WWiidd--ccllaasshh--len --WWllaarrggeerr--tthhaann--len --WWccoonnvveerrssiioonn --WWaaggggrreeggaattee--rreettuurrnn --WWrreedduunnddaanntt--ddeeccllss These options all could have some relevant meaning for GNU Fortran programs, but are not yet supported. OOppttiioonnss ffoorr DDeebbuuggggiinngg YYoouurr PPrrooggrraamm oorr GGNNUU FFoorrttrraann GNU Fortran has various special options that are used for debugging ei- ther your program or gg7777 --gg Produce debugging information in the operating system's native for- mat (stabs, COFF, XCOFF, or DWARF). GDB can work with this debug- ging information. A sample debugging session looks like this (note the use of the breakpoint): $ cat gdb.f PROGRAM PROG DIMENSION A(10) DATA A /1.,2.,3.,4.,5.,6.,7.,8.,9.,10./ A(5) = 4. PRINT*,A END $ g77 -g -O gdb.f $ gdb a.out ... (gdb) break MAIN__ Breakpoint 1 at 0x8048e96: file gdb.f, line 4. (gdb) run Starting program: /home/toon/g77-bugs/./a.out Breakpoint 1, MAIN__ () at gdb.f:4 4 A(5) = 4. Current language: auto; currently fortran (gdb) print a(5) $1 = 5 (gdb) step 5 PRINT*,A (gdb) print a(5) $2 = 4 ... One could also add the setting of the breakpoint and the first run command to the file .gdbinit in the current directory, to simplify the debugging session. OOppttiioonnss TThhaatt CCoonnttrrooll OOppttiimmiizzaattiioonn Most Fortran users will want to use no optimization when developing and testing programs, and use --OO or --OO22 when compiling programs for late- cycle testing and for production use. However, note that certain diag- nostics---such as for uninitialized variables---depend on the flow analysis done by --OO, i.e. you must use --OO or --OO22 to get such diagnos- tics. The following flags have particular applicability when compiling For- tran programs: --mmaalliiggnn--ddoouubbllee (Intel x86 architecture only.) Noticeably improves performance of gg7777 programs making heavy use of "REAL(KIND=2)" ("DOUBLE PRECISION") data on some systems. In par- ticular, systems using Pentium, Pentium Pro, 586, and 686 implemen- tations 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 ggcccc documentation about this option does not apply, generally speaking, to Fortran code compiled by gg7777 Also also note: The negative form of --mmaalliiggnn--ddoouubbllee is --mmnnoo--aalliiggnn-- ddoouubbllee, not --bbeenniiggnn--ddoouubbllee. --ffffllooaatt--ssttoorree Might help a Fortran program that depends on exact IEEE conformance on some machines, but might slow down a program that doesn't. This option is effective when the floating-point unit is set to work in IEEE 854 `extended precision'---as it typically is on x86 and m68k GNU systems---rather than IEEE 754 double precision. --ffffllooaatt--ssttoorree tries to remove the extra precision by spilling data from floating-point registers into memory and this typically in- volves a big performance hit. However, it doesn't affect interme- diate results, so that it is only partially effective. `Excess precision' is avoided in code like: a = b + c d = a * e but not in code like: d = (b + c) * e For another, potentially better, way of controlling the precision, see @ref{Floating-point precision}. --ffffoorrccee--mmeemm --ffffoorrccee--aaddddrr Might improve optimization of loops. --ffnnoo--iinnlliinnee 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. --ffffaasstt--mmaatthh Might allow some programs designed to not be too dependent on IEEE behavior for floating-point to run faster, or die trying. Sets --ffuunnssaaffee--mmaatthh--ooppttiimmiizzaattiioonnss, and --ffnnoo--ttrraappppiinngg--mmaatthh. --ffuunnssaaffee--mmaatthh--ooppttiimmiizzaattiioonnss Allow optimizations that may be give incorrect results for certain IEEE inputs. --ffnnoo--ttrraappppiinngg--mmaatthh Allow the compiler to assume that floating-point arithmetic will not generate traps on any inputs. This is useful, for example, when running a program using IEEE "non-stop" floating-point arith- metic. --ffssttrreennggtthh--rreedduuccee Might make some loops run faster. --ffrreerruunn--ccssee--aafftteerr--lloooopp --ffeexxppeennssiivvee--ooppttiimmiizzaattiioonnss --ffddeellaayyeedd--bbrraanncchh --ffsscchheedduullee--iinnssnnss --ffsscchheedduullee--iinnssnnss22 --ffccaalllleerr--ssaavveess Might improve performance on some code. --ffuunnrroollll--llooooppss Typically improves performance on code using iterative "DO" loops by unrolling them and is probably generally appropriate for For- tran, though it is not turned on at any optimization level. Note that outer loop unrolling isn't done specifically; decisions about whether to unroll a loop are made on the basis of its instruction count. Also, no `loop discovery'[1] is done, so only loops written with "DO" benefit from loop optimizations, including---but not limited to---unrolling. Loops written with "IF" and "GOTO" are not cur- rently recognized as such. This option unrolls only iterative "DO" loops, not "DO WHILE" loops. --ffuunnrroollll--aallll--llooooppss Probably improves performance on code using "DO WHILE" loops by un- rolling them in addition to iterative "DO" loops. In the absence of "DO WHILE", this option is equivalent to --ffuunnrroollll--llooooppss but pos- sibly slower. --ffnnoo--mmoovvee--aallll--mmoovvaabblleess --ffnnoo--rreedduuccee--aallll--ggiivvss --ffnnoo--rreerruunn--lloooopp--oopptt In general, the optimizations enabled with these options will lead to faster code being generated by GNU Fortran; hence they are en- abled by default when issuing the gg7777 command. --ffmmoovvee--aallll--mmoovvaabblleess and --ffrreedduuccee--aallll--ggiivvss will enable loop opti- mization to move all loop-invariant index computations in nested loops over multi-rank array dummy arguments out of these loops. --ffrreerruunn--lloooopp--oopptt will move offset calculations resulting from the fact that Fortran arrays by default have a lower bound of 1 out of the loops. These three options are intended to be removed someday, once loop optimization is sufficiently advanced to perform all those trans- formations without help from these options. OOppttiioonnss CCoonnttrroolllliinngg tthhee PPrreepprroocceessssoorr These options control the C preprocessor, which is run on each C source file before actual compilation. Some of these options also affect how gg7777 processes the "INCLUDE" di- rective. Since this directive is processed even when preprocessing is not requested, it is not described in this section. 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 con- taining preprocessor directives, if included, is necessarily included by a file that itself contains preprocessor directives. OOppttiioonnss ffoorr DDiirreeccttoorryy SSeeaarrcchh These options affect how the ccpppp preprocessor searches for files speci- fied via the "#include" directive. Therefore, when compiling Fortran programs, they are meaningful when the preprocessor is used. Some of these options also affect how gg7777 searches for files specified via the "INCLUDE" directive, although files included by that directive are not, themselves, preprocessed. These options are: --II-- --IIdir These affect interpretation of the "INCLUDE" directive (as well as of the "#include" directive of the ccpppp preprocessor). Note that --IIdir must be specified without any spaces between --II and the directory name---that is, --IIffoooo//bbaarr is valid, but --II ffoooo//bbaarr is rejected by the gg7777 compiler (though the preprocessor supports the latter form). Also note that the general behavior of --II and "IN- CLUDE" is pretty much the same as of --II with "#include" in the ccpppp preprocessor, with regard to looking for header.gcc files and other such things. OOppttiioonnss ffoorr CCooddee GGeenneerraattiioonn CCoonnvveennttiioonnss 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 --ffffoooo would be --ffnnoo--ffoooo. 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 nnoo-- or adding it. --ffnnoo--aauuttoommaattiicc Treat each program unit as if the "SAVE" statement was specified for every local variable and array referenced in it. Does not af- fect common blocks. (Some Fortran compilers provide this option under the name --ssttaattiicc.) --ffiinniitt--llooccaall--zzeerroo 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 --ffnnoo--aauuttoommaattiicc with --ffiinniitt--llooccaall--zzeerroo. --ffnnoo--ff22cc Do not generate code designed to be compatible with code generated by ff22cc use the GNU calling conventions instead. The ff22cc calling conventions require functions that return type "REAL(KIND=1)" to actually return the C type "double", and func- tions 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 "libg2c" library. However, because the "libg2c" library uses ff22cc calling conventions, gg7777 rejects attempts to pass intrinsics implemented by routines in this library as actual arguments when --ffnnoo--ff22cc is used, to avoid bugs when they are actually called by code expecting the GNU call- ing conventions to work. For example, IINNTTRRIINNSSIICC AABBSS;;CCAALLLL FFOOOO((AABBSS)) is rejected when --ffnnoo--ff22cc is in force. (Future versions of the gg7777 run-time library might offer routines that provide GNU-callable versions of the routines that implement the ff22cc intrinsics that may be passed as actual ar- guments, so that valid programs need not be rejected when --ffnnoo--ff22cc is used.) CCaauuttiioonn:: If --ffnnoo--ff22cc 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. --ffff22cc--lliibbrraarryy Specify that use of "libg2c" (or the original "libf2c") is re- quired. This is the default for the current version of gg7777 Currently it is not valid to specify --ffnnoo--ff22cc--lliibbrraarryy. 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 gg7777 that might otherwise de- fault to generating code for an incompatible library. --ffnnoo--uunnddeerrssccoorriinngg Do not transform names of entities specified in the Fortran source file by appending underscores to them. With --ffuunnddeerrssccoorriinngg in effect, gg7777 appends two underscores to names with underscores and one underscore to external names with no un- derscores. (gg7777 also appends two underscores to internal names with underscores to avoid naming collisions with external names. The --ffnnoo--sseeccoonndd--uunnddeerrssccoorree 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 ff22cc which perform the same trans- formations. Use of --ffnnoo--uunnddeerrssccoorriinngg is not recommended unless you are experi- menting with issues such as integration of (GNU) Fortran into ex- isting system environments (vis-a-vis existing libraries, tools, and so on). For example, with --ffuunnddeerrssccoorriinngg, and assuming other defaults like --ffccaassee--lloowweerr and that j() and max_count() are external functions while mmyy_vvaarr and llvvaarr 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 --ffnnoo--uunnddeerrssccoorriinngg, the same statement is implemented as: i = j() + max_count(&my_var, &lvar); Use of --ffnnoo--uunnddeerrssccoorriinngg allows direct specification of user-de- fined names while debugging and when interfacing gg7777 code with other languages. Note that just because the names match does not mean that the in- terface implemented by gg7777 for an external name matches the inter- face implemented by some other language for that same name. That is, getting code produced by gg7777 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 signifi- cant effort, and, unlike naming disagreements, linkers normally cannot detect disagreements in these other areas. Also, note that with --ffnnoo--uunnddeerrssccoorriinngg, the lack of appended under- scores introduces the very real possibility that a user-defined ex- ternal 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 gg7777 we hope to improve naming and linking is- sues so that debugging always involves using the names as they ap- pear in the source, even if the names as seen by the linker are mangled to prevent accidental linking between procedures with in- compatible interfaces. --ffnnoo--sseeccoonndd--uunnddeerrssccoorree Do not append a second underscore to names of entities specified in the Fortran source file. This option has no effect if --ffnnoo--uunnddeerrssccoorriinngg is in effect. Otherwise, with this option, an external name such as MMAAXX_CCOOUUNNTT is implemented as a reference to the link-time external symbol mmaaxx_ccoouunntt_, instead of mmaaxx_ccoouunntt__. --ffnnoo--iiddeenntt Ignore the ##iiddeenntt directive. --ffzzeerrooss Treat initial values of zero as if they were any other value. As of version 0.5.18, gg7777 normally treats "DATA" and other state- ments 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 pro- duced. This is done to speed up compiling of programs that initialize large arrays to zeros. Use --ffzzeerrooss to revert to the simpler, slower behavior that can catch multiple initializations by keeping track of all initializa- tions, zero or otherwise. Caution: Future versions of gg7777 might disregard this option (and its negative form, the default) or interpret it somewhat differ- ently. The interpretation changes will affect only non-standard programs; standard-conforming programs should not be affected. --ffeemmuullaattee--ccoommpplleexx Implement "COMPLEX" arithmetic via emulation, instead of using the facilities of the ggcccc back end that provide direct support of "com- plex" arithmetic. (ggcccc had some bugs in its back-end support for "complex" arith- metic, due primarily to the support not being completed as of ver- sion 2.8.1 and "egcs" 1.1.2.) Use --ffeemmuullaattee--ccoommpplleexx if you suspect code-generation bugs, or expe- rience compiler crashes, that might result from gg7777 using the "COM- PLEX" support in the ggcccc back end. If using that option fixes the bugs or crashes you are seeing, that indicates a likely gg7777 bugs (though, all compiler crashes are considered bugs), so, please re- port it. (Note that the known bugs, now believed fixed, produced compiler crashes rather than causing the generation of incorrect code.) Use of this option should not affect how Fortran code compiled by gg7777 works in terms of its interfaces to other code, e.g. that com- piled by ff22cc As of GCC version 3.0, this option is not necessary anymore. Caution: Future versions of gg7777 might ignore both forms of this op- tion. --ffaalliiaass--cchheecckk --ffaarrgguummeenntt--aalliiaass --ffaarrgguummeenntt--nnooaalliiaass --ffnnoo--aarrgguummeenntt--nnooaalliiaass--gglloobbaall Version info: These options are not supported by versions of gg7777 based on ggcccc version 2.8. These options specify to what degree aliasing (overlap) is permit- ted 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 --ffaarrgguummeenntt--nnooaalliiaass--gglloobbaall. The default for code written in the C language family is --ffaarrgguummeenntt--aalliiaass. Note that, on some systems, compiling with --ffffoorrccee--aaddddrr in effect can produce more optimal code when the default aliasing options are in effect (and when optimization is enabled). --ffnnoo--gglloobbaallss Disable diagnostics about inter-procedural analysis problems, such as disagreements about the type of a function or a procedure's ar- gument, 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 --WWnnoo--gglloobbaallss 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 diag- nosed. As such, this option might be quite useful when compiling existing, ``working'' code that happens to have a few bugs that do not gener- ally show themselves, but which gg7777 diagnoses. Use of this option therefore has the effect of instructing gg7777 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, gg7777 defaults to performing the potentially in- lining 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 as (fatal) errors, and warns about similar disagreements that are currently believed to not likely to result in the compiler later crashing or producing incor- rect code. --ffffllaatttteenn--aarrrraayyss Use back end's C-like constructs (pointer plus offset) instead of its "ARRAY_REF" construct to handle all array references. Note: This option is not supported. It is intended for use only by gg7777 developers, to evaluate code-generation issues. It might be removed at any time. --ffbboouunnddss--cchheecckk --ffffoorrttrraann--bboouunnddss--cchheecckk Enable generation of run-time checks for array subscripts and sub- string start and end points against the (locally) declared minimum and maximum values. The current implementation uses the "libf2c" library routine "s_rnge" to print the diagnostic. However, whereas ff22cc generates a single check per reference for a multi-dimensional array, of the computed offset against the valid offset range (0 through the size of the array), gg7777 generates a single check per subscript expression. This catches some cases of potential bugs that ff22cc does not, such as references to below the beginning of an assumed-size array. gg7777 also generates checks for "CHARACTER" substring references, something ff22cc currently does not do. Use the new --ffffoorrttrraann--bboouunnddss--cchheecckk option to specify bounds-check- ing for only the Fortran code you are compiling, not necessarily for code written in other languages. Note: To provide more detailed information on the offending sub- script, gg7777 provides the "libg2c" run-time library routine "s_rnge" with somewhat differently-formatted information. Here's a sample diagnostic: Subscript out of range on file line 4, procedure rnge.f/bf. Attempt to access the -6-th element of variable b[subscript-2-of-2]. Aborted The above message indicates that the offending source line is line 4 of the file rnge.f, within the program unit (or statement func- tion) named bbff. The offended array is named bb. The offended array dimension is the second for a two-dimensional array, and the of- fending, computed subscript expression was --66. For a "CHARACTER" substring reference, the second line has this ap- pearance: Attempt to access the 11-th element of variable a[start-substring]. This indicates that the offended "CHARACTER" variable or array is named aa, the offended substring position is the starting (leftmost) position, and the offending substring expression is 1111. (Though the verbage of "s_rnge" is not ideal for the purpose of the gg7777 compiler, the above information should provide adequate diag- nostic abilities to it users.) Some of these do not work when compiling programs written in Fortran: --ffppcccc--ssttrruucctt--rreettuurrnn --ffrreegg--ssttrruucctt--rreettuurrnn You should not use these except strictly the same way as you used them to build the version of "libg2c" with which you will be link- ing all code compiled by gg7777 with the same option. --ffsshhoorrtt--ddoouubbllee This probably either has no effect on Fortran programs, or makes them act loopy. --ffnnoo--ccoommmmoonn Do not use this when compiling Fortran programs, or there will be Trouble. --ffppaacckk--ssttrruucctt This probably will break any calls to the "libg2c" library, at the very least, even if it is built with the same option. E GNU Fortran currently does not make use of any environment variables to control its operation above and beyond those that affect the operation of ggcccc. B For instructions on reporting bugs, see <hhttttpp::////ggcccc..ggnnuu..oorrgg//bbuuggss..hhttmmll>. Use of the ggccccbbuugg script to report bugs is recommended. F 1. loop discovery refers to the process by which a compiler, or indeed any reader of a program, determines which portions of the program are more likely to be executed repeatedly as it is being run. Such discovery typically is done early when compiling using optimization techniques, so the ``discovered'' loops get more attention---and more run-time resources, such as registers---from the compiler. It is easy to ``discover'' loops that are constructed out of looping constructs in the language (such as Fortran's "DO"). For some pro- grams, ``discovering'' loops constructed out of lower-level con- structs (such as "IF" and "GOTO") can lead to generation of more optimal code than otherwise. S gpl(7), gfdl(7), fsf-funding(7), cpp(1), gcov(1), gcc(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1) and the Info entries for gcc, cpp, g77, as, ld, binutils and gdb. A See the Info entry for gg7777 for contributors to GCC and G77. C Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``Funding Free Software'', the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the gfdl(7) man page. (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. 3rd Berkeley Distribution gcc-3.2.2 G77(1)
N | S | D | O | E | B | F | S | A | C
Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=f77&sektion=1&manpath=FreeBSD+6.0-RELEASE+and+Ports>