Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
G77(1)				      GNU				G77(1)

       g77 - GNU project Fortran 77 compiler

       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-

       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.

       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

       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.

	   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

	   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.

	   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

       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:

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

	   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

	   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.

	   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:

	   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

	   These constructs are	considered inappropriate to use	in new or
	   well-maintained portable Fortran code, but widely used in old code.

	   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

	   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.

	   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.

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

	   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

	   Specify that	the source file	is written in free form	(introduced in
	   Fortran 90) instead of the more-traditional fixed form.

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

	   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.

	   Allow $$ as a	valid character	in a symbol name.

	   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.

	   Disallow passing Hollerith and typeless constants as	actual argu-
	   ments (for example, CCAALLLL FFOOOO((44HHAABBCCDD))).

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

	   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

	   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-

	   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 ==

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

	   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.

	   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

	   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.

	   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-

	   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.

	   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:

		   R = Z'ABCD1234'
		   J = Z'ABCD1234'
		   IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
		   IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'

	   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.

	   Specify expected case for intrinsic names.  --ffiinnttrriinn--ccaassee--lloowweerr is
	   the default.

	   Specify expected case for keywords.	--ffmmaattcchh--ccaassee--lloowweerr is the de-

	   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.

	   Specify valid cases for user-defined	symbol names.  --ffssyymmbbooll--ccaassee--
	   aannyy is the default.

	   Same	as --ffiinnttrriinn--ccaassee--uuppppeerr --ffmmaattcchh--ccaassee--uuppppeerr --ffssoouurrccee--ccaassee--pprree--
	   sseerrvvee --ffssyymmbbooll--ccaassee--uuppppeerr.  (Requires all pertinent source to be in

	   Same	as --ffiinnttrriinn--ccaassee--lloowweerr --ffmmaattcchh--ccaassee--lloowweerr --ffssoouurrccee--ccaassee--pprree--
	   sseerrvvee --ffssyymmbbooll--ccaassee--lloowweerr.  (Requires all pertinent source to be in

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

	   Same	as --ffiinnttrriinn--ccaassee--aannyy --ffmmaattcchh--ccaassee--aannyy --ffssoouurrccee--ccaassee--uuppppeerr
	   --ffssyymmbbooll--ccaassee--aannyy.  (Maps all pertinent source to uppercase.)

	   Same	as --ffiinnttrriinn--ccaassee--aannyy --ffmmaattcchh--ccaassee--aannyy --ffssoouurrccee--ccaassee--lloowweerr
	   --ffssyymmbbooll--ccaassee--aannyy.  (Maps all pertinent source to lowercase.)

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

	   Specify status of UNIX intrinsics having inappropriate forms.
	   --ffbbaadduu7777--iinnttrriinnssiiccss--eennaabbllee is the default.

	   Specify status of f2c-specific intrinsics.  --ffff22cc--iinnttrriinnssiiccss--eennaabbllee
	   is the default.

	   Specify status of F90-specific intrinsics.  --ffff9900--iinnttrriinnssiiccss--eennaabbllee
	   is the default.

	   Specify status of Digital's COMPLEX-related intrinsics.  --ffggnnuu--iinn--
	   ttrriinnssiiccss--eennaabbllee is the default.

	   Specify status of MIL-STD-1753-specific intrinsics.	--ffmmiill--iinnttrriinn--
	   ssiiccss--eennaabbllee is the default.

	   Specify status of UNIX intrinsics.  --ffuunniixx--iinnttrriinnssiiccss--eennaabbllee	is the

	   Specify status of VXT intrinsics.  --ffvvxxtt--iinnttrriinnssiiccss--eennaabbllee is the

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

       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

	   Check the code for syntax errors, but don't do anything beyond

	   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.

	   Like	--ppeeddaannttiicc, except that errors are produced rather than warn-

	   Like	--ppeeddaannttiicc, but applies only to Fortran constructs.

       --ww  Inhibit all warning messages.

	   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.

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

	   Warn	whenever a variable is unused aside from its declaration.

	   Warn	whenever an automatic variable is used without first being

	   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-

	   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

	   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

		   IF (J.EQ.1) I=1
		   IF (J.EQ.2) I=4
		   IF (J.EQ.3) I=5
		   CALL	FOO(I)

	   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:

		   IF (FLAG) VALUE = 9.4

	   This	has no bug because "VALUE" is used only	if it is set.

	   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.

	   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-

	       (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

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

	   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-

	   o   Overflows involving floating-point constants (not available for
	       certain configurations).

       Some of these have no effect when compiling programs written in For-

	   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

		   $ cat gdb.f
			 DATA A	/1.,2.,3.,4.,5.,6.,7.,8.,9.,10./
			 A(5) =	4.
		   $ 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-

       The following flags have	particular applicability when compiling	For-
       tran programs:

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

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

	   Might improve optimization of loops.

	   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.

	   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.

	   Allow optimizations that may	be give	incorrect results for certain
	   IEEE	inputs.

	   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-

	   Might make some loops run faster.

	   Might improve performance on	some code.

	   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

	   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.

	   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.

	   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:

	   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.

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

	   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.

	   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.

	   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.

	   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-

	   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.

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

	   Ignore the ##iiddeenntt directive.

	   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-

	   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.

	   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

	   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-

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

	   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-

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

	   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.

	   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

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

	   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-

		   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:

	   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.

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

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

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

       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.

       For instructions	on reporting bugs, see <hhttttpp::////ggcccc..ggnnuu..oorrgg//bbuuggss..hhttmmll>.
       Use of the ggccccbbuugg script	to report bugs is recommended.

       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.

       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.

       See the Info entry for gg7777 for contributors to GCC and G77.

       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:

home | help