X-Git-Url: https://oss.titaniummirror.com/gitweb?a=blobdiff_plain;f=gcc%2Ff%2Fg77.info-11;fp=gcc%2Ff%2Fg77.info-11;h=0000000000000000000000000000000000000000;hb=6fed43773c9b0ce596dca5686f37ac3fc0fa11c0;hp=e7846dedef04d6742cdde56fe59244894a89ec0a;hpb=27b11d56b743098deb193d510b337ba22dc52e5c;p=msp430-gcc.git diff --git a/gcc/f/g77.info-11 b/gcc/f/g77.info-11 deleted file mode 100644 index e7846ded..00000000 --- a/gcc/f/g77.info-11 +++ /dev/null @@ -1,1317 +0,0 @@ -This is g77.info, produced by makeinfo version 4.5 from g77.texi. - -INFO-DIR-SECTION Programming -START-INFO-DIR-ENTRY -* g77: (g77). The GNU Fortran compiler. -END-INFO-DIR-ENTRY - This file documents the use and the internals of the GNU Fortran -(`g77') compiler. It corresponds to the GCC-3.2.3 version of `g77'. - - Published by the Free Software Foundation 59 Temple Place - Suite 330 -Boston, MA 02111-1307 USA - - Copyright (C) 1995,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 section entitled "GNU Free Documentation License". - - (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. - - Contributed by James Craig Burley (). Inspired by -a first pass at translating `g77-0.5.16/f/DOC' that was contributed to -Craig by David Ronis (). - - -File: g77.info, Node: Case Sensitivity, Next: VXT Fortran, Prev: Dollar Signs, Up: Other Dialects - -Case Sensitivity -================ - - GNU Fortran offers the programmer way too much flexibility in -deciding how source files are to be treated vis-a-vis uppercase and -lowercase characters. There are 66 useful settings that affect case -sensitivity, plus 10 settings that are nearly useless, with the -remaining 116 settings being either redundant or useless. - - None of these settings have any effect on the contents of comments -(the text after a `c' or `C' in Column 1, for example) or of character -or Hollerith constants. Note that things like the `E' in the statement -`CALL FOO(3.2E10)' and the `TO' in `ASSIGN 10 TO LAB' are considered -built-in keywords, and so are affected by these settings. - - Low-level switches are identified in this section as follows: - - A Source Case Conversion: - - 0 Preserve (see Note 1) - - 1 Convert to Upper Case - - 2 Convert to Lower Case - - B Built-in Keyword Matching: - - 0 Match Any Case (per-character basis) - - 1 Match Upper Case Only - - 2 Match Lower Case Only - - 3 Match InitialCaps Only (see tables for spellings) - - C Built-in Intrinsic Matching: - - 0 Match Any Case (per-character basis) - - 1 Match Upper Case Only - - 2 Match Lower Case Only - - 3 Match InitialCaps Only (see tables for spellings) - - D User-defined Symbol Possibilities (warnings only): - - 0 Allow Any Case (per-character basis) - - 1 Allow Upper Case Only - - 2 Allow Lower Case Only - - 3 Allow InitialCaps Only (see Note 2) - - Note 1: `g77' eventually will support `NAMELIST' in a manner that is -consistent with these source switches--in the sense that input will be -expected to meet the same requirements as source code in terms of -matching symbol names and keywords (for the exponent letters). - - Currently, however, `NAMELIST' is supported by `libg2c', which -uppercases `NAMELIST' input and symbol names for matching. This means -not only that `NAMELIST' output currently shows symbol (and keyword) -names in uppercase even if lower-case source conversion (option A2) is -selected, but that `NAMELIST' cannot be adequately supported when -source case preservation (option A0) is selected. - - If A0 is selected, a warning message will be output for each -`NAMELIST' statement to this effect. The behavior of the program is -undefined at run time if two or more symbol names appear in a given -`NAMELIST' such that the names are identical when converted to upper -case (e.g. `NAMELIST /X/ VAR, Var, var'). For complete and total -elegance, perhaps there should be a warning when option A2 is selected, -since the output of NAMELIST is currently in uppercase but will someday -be lowercase (when a `libg77' is written), but that seems to be -overkill for a product in beta test. - - Note 2: Rules for InitialCaps names are: - - - Must be a single uppercase letter, *or* - - - Must start with an uppercase letter and contain at least one - lowercase letter. - - So `A', `Ab', `ABc', `AbC', and `Abc' are valid InitialCaps names, -but `AB', `A2', and `ABC' are not. Note that most, but not all, -built-in names meet these requirements--the exceptions are some of the -two-letter format specifiers, such as `BN' and `BZ'. - - Here are the names of the corresponding command-line options: - - A0: -fsource-case-preserve - A1: -fsource-case-upper - A2: -fsource-case-lower - - B0: -fmatch-case-any - B1: -fmatch-case-upper - B2: -fmatch-case-lower - B3: -fmatch-case-initcap - - C0: -fintrin-case-any - C1: -fintrin-case-upper - C2: -fintrin-case-lower - C3: -fintrin-case-initcap - - D0: -fsymbol-case-any - D1: -fsymbol-case-upper - D2: -fsymbol-case-lower - D3: -fsymbol-case-initcap - - Useful combinations of the above settings, along with abbreviated -option names that set some of these combinations all at once: - - 1: A0-- B0--- C0--- D0--- -fcase-preserve - 2: A0-- B0--- C0--- D-1-- - 3: A0-- B0--- C0--- D--2- - 4: A0-- B0--- C0--- D---3 - 5: A0-- B0--- C-1-- D0--- - 6: A0-- B0--- C-1-- D-1-- - 7: A0-- B0--- C-1-- D--2- - 8: A0-- B0--- C-1-- D---3 - 9: A0-- B0--- C--2- D0--- - 10: A0-- B0--- C--2- D-1-- - 11: A0-- B0--- C--2- D--2- - 12: A0-- B0--- C--2- D---3 - 13: A0-- B0--- C---3 D0--- - 14: A0-- B0--- C---3 D-1-- - 15: A0-- B0--- C---3 D--2- - 16: A0-- B0--- C---3 D---3 - 17: A0-- B-1-- C0--- D0--- - 18: A0-- B-1-- C0--- D-1-- - 19: A0-- B-1-- C0--- D--2- - 20: A0-- B-1-- C0--- D---3 - 21: A0-- B-1-- C-1-- D0--- - 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper - 23: A0-- B-1-- C-1-- D--2- - 24: A0-- B-1-- C-1-- D---3 - 25: A0-- B-1-- C--2- D0--- - 26: A0-- B-1-- C--2- D-1-- - 27: A0-- B-1-- C--2- D--2- - 28: A0-- B-1-- C--2- D---3 - 29: A0-- B-1-- C---3 D0--- - 30: A0-- B-1-- C---3 D-1-- - 31: A0-- B-1-- C---3 D--2- - 32: A0-- B-1-- C---3 D---3 - 33: A0-- B--2- C0--- D0--- - 34: A0-- B--2- C0--- D-1-- - 35: A0-- B--2- C0--- D--2- - 36: A0-- B--2- C0--- D---3 - 37: A0-- B--2- C-1-- D0--- - 38: A0-- B--2- C-1-- D-1-- - 39: A0-- B--2- C-1-- D--2- - 40: A0-- B--2- C-1-- D---3 - 41: A0-- B--2- C--2- D0--- - 42: A0-- B--2- C--2- D-1-- - 43: A0-- B--2- C--2- D--2- -fcase-strict-lower - 44: A0-- B--2- C--2- D---3 - 45: A0-- B--2- C---3 D0--- - 46: A0-- B--2- C---3 D-1-- - 47: A0-- B--2- C---3 D--2- - 48: A0-- B--2- C---3 D---3 - 49: A0-- B---3 C0--- D0--- - 50: A0-- B---3 C0--- D-1-- - 51: A0-- B---3 C0--- D--2- - 52: A0-- B---3 C0--- D---3 - 53: A0-- B---3 C-1-- D0--- - 54: A0-- B---3 C-1-- D-1-- - 55: A0-- B---3 C-1-- D--2- - 56: A0-- B---3 C-1-- D---3 - 57: A0-- B---3 C--2- D0--- - 58: A0-- B---3 C--2- D-1-- - 59: A0-- B---3 C--2- D--2- - 60: A0-- B---3 C--2- D---3 - 61: A0-- B---3 C---3 D0--- - 62: A0-- B---3 C---3 D-1-- - 63: A0-- B---3 C---3 D--2- - 64: A0-- B---3 C---3 D---3 -fcase-initcap - 65: A-1- B01-- C01-- D01-- -fcase-upper - 66: A--2 B0-2- C0-2- D0-2- -fcase-lower - - Number 22 is the "strict" ANSI FORTRAN 77 model wherein all input -(except comments, character constants, and Hollerith strings) must be -entered in uppercase. Use `-fcase-strict-upper' to specify this -combination. - - Number 43 is like Number 22 except all input must be lowercase. Use -`-fcase-strict-lower' to specify this combination. - - Number 65 is the "classic" ANSI FORTRAN 77 model as implemented on -many non-UNIX machines whereby all the source is translated to -uppercase. Use `-fcase-upper' to specify this combination. - - Number 66 is the "canonical" UNIX model whereby all the source is -translated to lowercase. Use `-fcase-lower' to specify this -combination. - - There are a few nearly useless combinations: - - 67: A-1- B01-- C01-- D--2- - 68: A-1- B01-- C01-- D---3 - 69: A-1- B01-- C--23 D01-- - 70: A-1- B01-- C--23 D--2- - 71: A-1- B01-- C--23 D---3 - 72: A--2 B01-- C0-2- D-1-- - 73: A--2 B01-- C0-2- D---3 - 74: A--2 B01-- C-1-3 D0-2- - 75: A--2 B01-- C-1-3 D-1-- - 76: A--2 B01-- C-1-3 D---3 - - The above allow some programs to be compiled but with restrictions -that make most useful programs impossible: Numbers 67 and 72 warn about -_any_ user-defined symbol names (such as `SUBROUTINE FOO'); Numbers 68 -and 73 warn about any user-defined symbol names longer than one -character that don't have at least one non-alphabetic character after -the first; Numbers 69 and 74 disallow any references to intrinsics; and -Numbers 70, 71, 75, and 76 are combinations of the restrictions in -67+69, 68+69, 72+74, and 73+74, respectively. - - All redundant combinations are shown in the above tables anyplace -where more than one setting is shown for a low-level switch. For -example, `B0-2-' means either setting 0 or 2 is valid for switch B. -The "proper" setting in such a case is the one that copies the setting -of switch A--any other setting might slightly reduce the speed of the -compiler, though possibly to an unmeasurable extent. - - All remaining combinations are useless in that they prevent -successful compilation of non-null source files (source files with -something other than comments). - - -File: g77.info, Node: VXT Fortran, Next: Fortran 90, Prev: Case Sensitivity, Up: Other Dialects - -VXT Fortran -=========== - - `g77' supports certain constructs that have different meanings in -VXT Fortran than they do in the GNU Fortran language. - - Generally, this manual uses the invented term VXT Fortran to refer -VAX FORTRAN (circa v4). That compiler offered many popular features, -though not necessarily those that are specific to the VAX processor -architecture, the VMS operating system, or Digital Equipment -Corporation's Fortran product line. (VAX and VMS probably are -trademarks of Digital Equipment Corporation.) - - An extension offered by a Digital Fortran product that also is -offered by several other Fortran products for different kinds of -systems is probably going to be considered for inclusion in `g77' -someday, and is considered a VXT Fortran feature. - - The `-fvxt' option generally specifies that, where the meaning of a -construct is ambiguous (means one thing in GNU Fortran and another in -VXT Fortran), the VXT Fortran meaning is to be assumed. - -* Menu: - -* Double Quote Meaning:: `"2000' as octal constant. -* Exclamation Point:: `!' in column 6. - - -File: g77.info, Node: Double Quote Meaning, Next: Exclamation Point, Up: VXT Fortran - -Meaning of Double Quote ------------------------ - - `g77' treats double-quote (`"') as beginning an octal constant of -`INTEGER(KIND=1)' type when the `-fvxt' option is specified. The form -of this octal constant is - - "OCTAL-DIGITS - -where OCTAL-DIGITS is a nonempty string of characters in the set -`01234567'. - - For example, the `-fvxt' option permits this: - - PRINT *, "20 - END - -The above program would print the value `16'. - - *Note Integer Type::, for information on the preferred construct for -integer constants specified using GNU Fortran's octal notation. - - (In the GNU Fortran language, the double-quote character (`"') -delimits a character constant just as does apostrophe (`''). There is -no way to allow both constructs in the general case, since statements -like `PRINT *,"2000 !comment?"' would be ambiguous.) - - -File: g77.info, Node: Exclamation Point, Prev: Double Quote Meaning, Up: VXT Fortran - -Meaning of Exclamation Point in Column 6 ----------------------------------------- - - `g77' treats an exclamation point (`!') in column 6 of a fixed-form -source file as a continuation character rather than as the beginning of -a comment (as it does in any other column) when the `-fvxt' option is -specified. - - The following program, when run, prints a message indicating whether -it is interpreted according to GNU Fortran (and Fortran 90) rules or -VXT Fortran rules: - - C234567 (This line begins in column 1.) - I = 0 - !1 - IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program' - IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program' - IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer' - END - - (In the GNU Fortran and Fortran 90 languages, exclamation point is a -valid character and, unlike space () or zero (`0'), marks a line -as a continuation line when it appears in column 6.) - - -File: g77.info, Node: Fortran 90, Next: Pedantic Compilation, Prev: VXT Fortran, Up: Other Dialects - -Fortran 90 -========== - - The GNU Fortran language includes a number of features that are part -of Fortran 90, even when the `-ff90' option is not specified. The -features enabled by `-ff90' are intended to be those that, when `-ff90' -is not specified, would have another meaning to `g77'--usually meaning -something invalid in the GNU Fortran language. - - So, the purpose of `-ff90' is not to specify whether `g77' is to -gratuitously reject Fortran 90 constructs. The `-pedantic' option -specified with `-fno-f90' is intended to do that, although its -implementation is certainly incomplete at this point. - - When `-ff90' is specified: - - * The type of `REAL(EXPR)' and `AIMAG(EXPR)', where EXPR is - `COMPLEX' type, is the same type as the real part of EXPR. - - For example, assuming `Z' is type `COMPLEX(KIND=2)', `REAL(Z)' - would return a value of type `REAL(KIND=2)', not of type - `REAL(KIND=1)', since `-ff90' is specified. - - -File: g77.info, Node: Pedantic Compilation, Next: Distensions, Prev: Fortran 90, Up: Other Dialects - -Pedantic Compilation -==================== - - The `-fpedantic' command-line option specifies that `g77' is to warn -about code that is not standard-conforming. This is useful for finding -some extensions `g77' accepts that other compilers might not accept. -(Note that the `-pedantic' and `-pedantic-errors' options always imply -`-fpedantic'.) - - With `-fno-f90' in force, ANSI FORTRAN 77 is used as the standard -for conforming code. With `-ff90' in force, Fortran 90 is used. - - The constructs for which `g77' issues diagnostics when `-fpedantic' -and `-fno-f90' are in force are: - - * Automatic arrays, as in - - SUBROUTINE X(N) - REAL A(N) - ... - - where `A' is not listed in any `ENTRY' statement, and thus is not - a dummy argument. - - * The commas in `READ (5), I' and `WRITE (10), J'. - - These commas are disallowed by FORTRAN 77, but, while strictly - superfluous, are syntactically elegant, especially given that - commas are required in statements such as `READ 99, I' and `PRINT - *, J'. Many compilers permit the superfluous commas for this - reason. - - * `DOUBLE COMPLEX', either explicitly or implicitly. - - An explicit use of this type is via a `DOUBLE COMPLEX' or - `IMPLICIT DOUBLE COMPLEX' statement, for examples. - - An example of an implicit use is the expression `C*D', where `C' - is `COMPLEX(KIND=1)' and `D' is `DOUBLE PRECISION'. This - expression is prohibited by ANSI FORTRAN 77 because the rules of - promotion would suggest that it produce a `DOUBLE COMPLEX' - result--a type not provided for by that standard. - - * Automatic conversion of numeric expressions to `INTEGER(KIND=1)' - in contexts such as: - - - Array-reference indexes. - - - Alternate-return values. - - - Computed `GOTO'. - - - `FORMAT' run-time expressions (not yet supported). - - - Dimension lists in specification statements. - - - Numbers for I/O statements (such as `READ (UNIT=3.2), I') - - - Sizes of `CHARACTER' entities in specification statements. - - - Kind types in specification entities (a Fortran 90 feature). - - - Initial, terminal, and incrementation parameters for - implied-`DO' constructs in `DATA' statements. - - * Automatic conversion of `LOGICAL' expressions to `INTEGER' in - contexts such as arithmetic `IF' (where `COMPLEX' expressions are - disallowed anyway). - - * Zero-size array dimensions, as in: - - INTEGER I(10,20,4:2) - - * Zero-length `CHARACTER' entities, as in: - - PRINT *, '' - - * Substring operators applied to character constants and named - constants, as in: - - PRINT *, 'hello'(3:5) - - * Null arguments passed to statement function, as in: - - PRINT *, FOO(,3) - - * Disagreement among program units regarding whether a given `COMMON' - area is `SAVE'd (for targets where program units in a single source - file are "glued" together as they typically are for UNIX - development environments). - - * Disagreement among program units regarding the size of a named - `COMMON' block. - - * Specification statements following first `DATA' statement. - - (In the GNU Fortran language, `DATA I/1/' may be followed by - `INTEGER J', but not `INTEGER I'. The `-fpedantic' option - disallows both of these.) - - * Semicolon as statement separator, as in: - - CALL FOO; CALL BAR - - * Use of `&' in column 1 of fixed-form source (to indicate - continuation). - - * Use of `CHARACTER' constants to initialize numeric entities, and - vice versa. - - * Expressions having two arithmetic operators in a row, such as - `X*-Y'. - - If `-fpedantic' is specified along with `-ff90', the following -constructs result in diagnostics: - - * Use of semicolon as a statement separator on a line that has an - `INCLUDE' directive. - - -File: g77.info, Node: Distensions, Prev: Pedantic Compilation, Up: Other Dialects - -Distensions -=========== - - The `-fugly-*' command-line options determine whether certain -features supported by VAX FORTRAN and other such compilers, but -considered too ugly to be in code that can be changed to use safer -and/or more portable constructs, are accepted. These are humorously -referred to as "distensions", extensions that just plain look ugly in -the harsh light of day. - -* Menu: - -* Ugly Implicit Argument Conversion:: Disabled via `-fno-ugly-args'. -* Ugly Assumed-Size Arrays:: Enabled via `-fugly-assumed'. -* Ugly Null Arguments:: Enabled via `-fugly-comma'. -* Ugly Complex Part Extraction:: Enabled via `-fugly-complex'. -* Ugly Conversion of Initializers:: Disabled via `-fno-ugly-init'. -* Ugly Integer Conversions:: Enabled via `-fugly-logint'. -* Ugly Assigned Labels:: Enabled via `-fugly-assign'. - - -File: g77.info, Node: Ugly Implicit Argument Conversion, Next: Ugly Assumed-Size Arrays, Up: Distensions - -Implicit Argument Conversion ----------------------------- - - The `-fno-ugly-args' option disables passing typeless and Hollerith -constants as actual arguments in procedure invocations. For example: - - CALL FOO(4HABCD) - CALL BAR('123'O) - -These constructs can be too easily used to create non-portable code, -but are not considered as "ugly" as others. Further, they are widely -used in existing Fortran source code in ways that often are quite -portable. Therefore, they are enabled by default. - - -File: g77.info, Node: Ugly Assumed-Size Arrays, Next: Ugly Null Arguments, Prev: Ugly Implicit Argument Conversion, Up: Distensions - -Ugly Assumed-Size Arrays ------------------------- - - The `-fugly-assumed' option enables the treatment of any array with -a final dimension specified as `1' as an assumed-size array, as if `*' -had been specified instead. - - For example, `DIMENSION X(1)' is treated as if it had read -`DIMENSION X(*)' if `X' is listed as a dummy argument in a preceding -`SUBROUTINE', `FUNCTION', or `ENTRY' statement in the same program unit. - - Use an explicit lower bound to avoid this interpretation. For -example, `DIMENSION X(1:1)' is never treated as if it had read -`DIMENSION X(*)' or `DIMENSION X(1:*)'. Nor is `DIMENSION X(2-1)' -affected by this option, since that kind of expression is unlikely to -have been intended to designate an assumed-size array. - - This option is used to prevent warnings being issued about apparent -out-of-bounds reference such as `X(2) = 99'. - - It also prevents the array from being used in contexts that disallow -assumed-size arrays, such as `PRINT *,X'. In such cases, a diagnostic -is generated and the source file is not compiled. - - The construct affected by this option is used only in old code that -pre-exists the widespread acceptance of adjustable and assumed-size -arrays in the Fortran community. - - _Note:_ This option does not affect how `DIMENSION X(1)' is treated -if `X' is listed as a dummy argument only _after_ the `DIMENSION' -statement (presumably in an `ENTRY' statement). For example, -`-fugly-assumed' has no effect on the following program unit: - - SUBROUTINE X - REAL A(1) - RETURN - ENTRY Y(A) - PRINT *, A - END - - -File: g77.info, Node: Ugly Complex Part Extraction, Next: Ugly Conversion of Initializers, Prev: Ugly Null Arguments, Up: Distensions - -Ugly Complex Part Extraction ----------------------------- - - The `-fugly-complex' option enables use of the `REAL()' and `AIMAG()' -intrinsics with arguments that are `COMPLEX' types other than -`COMPLEX(KIND=1)'. - - With `-ff90' in effect, these intrinsics return the unconverted real -and imaginary parts (respectively) of their argument. - - With `-fno-f90' in effect, these intrinsics convert the real and -imaginary parts to `REAL(KIND=1)', and return the result of that -conversion. - - Due to this ambiguity, the GNU Fortran language defines these -constructs as invalid, except in the specific case where they are -entirely and solely passed as an argument to an invocation of the -`REAL()' intrinsic. For example, - - REAL(REAL(Z)) - -is permitted even when `Z' is `COMPLEX(KIND=2)' and `-fno-ugly-complex' -is in effect, because the meaning is clear. - - `g77' enforces this restriction, unless `-fugly-complex' is -specified, in which case the appropriate interpretation is chosen and -no diagnostic is issued. - - *Note CMPAMBIG::, for information on how to cope with existing code -with unclear expectations of `REAL()' and `AIMAG()' with -`COMPLEX(KIND=2)' arguments. - - *Note RealPart Intrinsic::, for information on the `REALPART()' -intrinsic, used to extract the real part of a complex expression -without conversion. *Note ImagPart Intrinsic::, for information on the -`IMAGPART()' intrinsic, used to extract the imaginary part of a complex -expression without conversion. - - -File: g77.info, Node: Ugly Null Arguments, Next: Ugly Complex Part Extraction, Prev: Ugly Assumed-Size Arrays, Up: Distensions - -Ugly Null Arguments -------------------- - - The `-fugly-comma' option enables use of a single trailing comma to -mean "pass an extra trailing null argument" in a list of actual -arguments to an external procedure, and use of an empty list of -arguments to such a procedure to mean "pass a single null argument". - - (Null arguments often are used in some procedure-calling schemes to -indicate omitted arguments.) - - For example, `CALL FOO(,)' means "pass two null arguments", rather -than "pass one null argument". Also, `CALL BAR()' means "pass one null -argument". - - This construct is considered "ugly" because it does not provide an -elegant way to pass a single null argument that is syntactically -distinct from passing no arguments. That is, this construct changes -the meaning of code that makes no use of the construct. - - So, with `-fugly-comma' in force, `CALL FOO()' and `I = JFUNC()' -pass a single null argument, instead of passing no arguments as -required by the Fortran 77 and 90 standards. - - _Note:_ Many systems gracefully allow the case where a procedure -call passes one extra argument that the called procedure does not -expect. - - So, in practice, there might be no difference in the behavior of a -program that does `CALL FOO()' or `I = JFUNC()' and is compiled with -`-fugly-comma' in force as compared to its behavior when compiled with -the default, `-fno-ugly-comma', in force, assuming `FOO' and `JFUNC' do -not expect any arguments to be passed. - - -File: g77.info, Node: Ugly Conversion of Initializers, Next: Ugly Integer Conversions, Prev: Ugly Complex Part Extraction, Up: Distensions - -Ugly Conversion of Initializers -------------------------------- - - The constructs disabled by `-fno-ugly-init' are: - - * Use of Hollerith and typeless constants in contexts where they set - initial (compile-time) values for variables, arrays, and named - constants--that is, `DATA' and `PARAMETER' statements, plus - type-declaration statements specifying initial values. - - Here are some sample initializations that are disabled by the - `-fno-ugly-init' option: - - PARAMETER (VAL='9A304FFE'X) - REAL*8 STRING/8HOUTPUT00/ - DATA VAR/4HABCD/ - - * In the same contexts as above, use of character constants to - initialize numeric items and vice versa (one constant per item). - - Here are more sample initializations that are disabled by the - `-fno-ugly-init' option: - - INTEGER IA - CHARACTER BELL - PARAMETER (IA = 'A') - PARAMETER (BELL = 7) - - * Use of Hollerith and typeless constants on the right-hand side of - assignment statements to numeric types, and in other contexts - (such as passing arguments in invocations of intrinsic procedures - and statement functions) that are treated as assignments to known - types (the dummy arguments, in these cases). - - Here are sample statements that are disabled by the - `-fno-ugly-init' option: - - IVAR = 4HABCD - PRINT *, IMAX0(2HAB, 2HBA) - - The above constructs, when used, can tend to result in non-portable -code. But, they are widely used in existing Fortran code in ways that -often are quite portable. Therefore, they are enabled by default. - - -File: g77.info, Node: Ugly Integer Conversions, Next: Ugly Assigned Labels, Prev: Ugly Conversion of Initializers, Up: Distensions - -Ugly Integer Conversions ------------------------- - - The constructs enabled via `-fugly-logint' are: - - * Automatic conversion between `INTEGER' and `LOGICAL' as dictated by - context (typically implies nonportable dependencies on how a - particular implementation encodes `.TRUE.' and `.FALSE.'). - - * Use of a `LOGICAL' variable in `ASSIGN' and assigned-`GOTO' - statements. - - The above constructs are disabled by default because use of them -tends to lead to non-portable code. Even existing Fortran code that -uses that often turns out to be non-portable, if not outright buggy. - - Some of this is due to differences among implementations as far as -how `.TRUE.' and `.FALSE.' are encoded as `INTEGER' values--Fortran -code that assumes a particular coding is likely to use one of the above -constructs, and is also likely to not work correctly on implementations -using different encodings. - - *Note Equivalence Versus Equality::, for more information. - - -File: g77.info, Node: Ugly Assigned Labels, Prev: Ugly Integer Conversions, Up: Distensions - -Ugly Assigned Labels --------------------- - - The `-fugly-assign' option forces `g77' to use the same storage for -assigned labels as it would for a normal assignment to the same -variable. - - For example, consider the following code fragment: - - I = 3 - ASSIGN 10 TO I - -Normally, for portability and improved diagnostics, `g77' reserves -distinct storage for a "sibling" of `I', used only for `ASSIGN' -statements to that variable (along with the corresponding -assigned-`GOTO' and assigned-`FORMAT'-I/O statements that reference the -variable). - - However, some code (that violates the ANSI FORTRAN 77 standard) -attempts to copy assigned labels among variables involved with `ASSIGN' -statements, as in: - - ASSIGN 10 TO I - ISTATE(5) = I - ... - J = ISTATE(ICUR) - GOTO J - -Such code doesn't work under `g77' unless `-fugly-assign' is specified -on the command-line, ensuring that the value of `I' referenced in the -second line is whatever value `g77' uses to designate statement label -`10', so the value may be copied into the `ISTATE' array, later -retrieved into a variable of the appropriate type (`J'), and used as -the target of an assigned-`GOTO' statement. - - _Note:_ To avoid subtle program bugs, when `-fugly-assign' is -specified, `g77' requires the type of variables specified in -assigned-label contexts _must_ be the same type returned by `%LOC()'. -On many systems, this type is effectively the same as -`INTEGER(KIND=1)', while, on others, it is effectively the same as -`INTEGER(KIND=2)'. - - Do _not_ depend on `g77' actually writing valid pointers to these -variables, however. While `g77' currently chooses that implementation, -it might be changed in the future. - - *Note Assigned Statement Labels (ASSIGN and GOTO): Assigned -Statement Labels, for implementation details on assigned-statement -labels. - - -File: g77.info, Node: Compiler, Next: Other Dialects, Prev: Language, Up: Top - -The GNU Fortran Compiler -************************ - - The GNU Fortran compiler, `g77', supports programs written in the -GNU Fortran language and in some other dialects of Fortran. - - Some aspects of how `g77' works are universal regardless of dialect, -and yet are not properly part of the GNU Fortran language itself. -These are described below. - - _Note: This portion of the documentation definitely needs a lot of -work!_ - -* Menu: - -* Compiler Limits:: -* Run-time Environment Limits:: -* Compiler Types:: -* Compiler Constants:: -* Compiler Intrinsics:: - - -File: g77.info, Node: Compiler Limits, Next: Run-time Environment Limits, Up: Compiler - -Compiler Limits -=============== - - `g77', as with GNU tools in general, imposes few arbitrary -restrictions on lengths of identifiers, number of continuation lines, -number of external symbols in a program, and so on. - - For example, some other Fortran compiler have an option (such as -`-NlX') to increase the limit on the number of continuation lines. -Also, some Fortran compilation systems have an option (such as `-NxX') -to increase the limit on the number of external symbols. - - `g77', `gcc', and GNU `ld' (the GNU linker) have no equivalent -options, since they do not impose arbitrary limits in these areas. - - `g77' does currently limit the number of dimensions in an array to -the same degree as do the Fortran standards--seven (7). This -restriction might be lifted in a future version. - - -File: g77.info, Node: Run-time Environment Limits, Next: Compiler Types, Prev: Compiler Limits, Up: Compiler - -Run-time Environment Limits -=========================== - - As a portable Fortran implementation, `g77' offers its users direct -access to, and otherwise depends upon, the underlying facilities of the -system used to build `g77', the system on which `g77' itself is used to -compile programs, and the system on which the `g77'-compiled program is -actually run. (For most users, the three systems are of the same -type--combination of operating environment and hardware--often the same -physical system.) - - The run-time environment for a particular system inevitably imposes -some limits on a program's use of various system facilities. These -limits vary from system to system. - - Even when such limits might be well beyond the possibility of being -encountered on a particular system, the `g77' run-time environment has -certain built-in limits, usually, but not always, stemming from -intrinsics with inherently limited interfaces. - - Currently, the `g77' run-time environment does not generally offer a -less-limiting environment by augmenting the underlying system's own -environment. - - Therefore, code written in the GNU Fortran language, while -syntactically and semantically portable, might nevertheless make -non-portable assumptions about the run-time environment--assumptions -that prove to be false for some particular environments. - - The GNU Fortran language, the `g77' compiler and run-time -environment, and the `g77' documentation do not yet offer comprehensive -portable work-arounds for such limits, though programmers should be -able to find their own in specific instances. - - Not all of the limitations are described in this document. Some of -the known limitations include: - -* Menu: - -* Timer Wraparounds:: -* Year 2000 (Y2K) Problems:: -* Array Size:: -* Character-variable Length:: -* Year 10000 (Y10K) Problems:: - - -File: g77.info, Node: Timer Wraparounds, Next: Year 2000 (Y2K) Problems, Up: Run-time Environment Limits - -Timer Wraparounds ------------------ - - Intrinsics that return values computed from system timers, whether -elapsed (wall-clock) timers, process CPU timers, or other kinds of -timers, are prone to experiencing wrap-around errors (or returning -wrapped-around values from successive calls) due to insufficient ranges -offered by the underlying system's timers. - - Some of the symptoms of such behaviors include apparently negative -time being computed for a duration, an extremely short amount of time -being computed for a long duration, and an extremely long amount of -time being computed for a short duration. - - See the following for intrinsics known to have potential problems in -these areas on at least some systems: *Note CPU_Time Intrinsic::, *Note -DTime Intrinsic (function)::, *Note DTime Intrinsic (subroutine)::, -*Note ETime Intrinsic (function)::, *Note ETime Intrinsic -(subroutine)::, *Note MClock Intrinsic::, *Note MClock8 Intrinsic::, -*Note Secnds Intrinsic::, *Note Second Intrinsic (function)::, *Note -Second Intrinsic (subroutine)::, *Note System_Clock Intrinsic::, *Note -Time Intrinsic (UNIX)::, *Note Time Intrinsic (VXT)::, *Note Time8 -Intrinsic::. - - -File: g77.info, Node: Year 2000 (Y2K) Problems, Next: Array Size, Prev: Timer Wraparounds, Up: Run-time Environment Limits - -Year 2000 (Y2K) Problems ------------------------- - - While the `g77' compiler itself is believed to be Year-2000 (Y2K) -compliant, some intrinsics are not, and, potentially, some underlying -systems are not, perhaps rendering some Y2K-compliant intrinsics -non-compliant when used on those particular systems. - - Fortran code that uses non-Y2K-compliant intrinsics (listed below) -is, itself, almost certainly not compliant, and should be modified to -use Y2K-compliant intrinsics instead. - - Fortran code that uses no non-Y2K-compliant intrinsics, but which -currently is running on a non-Y2K-compliant system, can be made more -Y2K compliant by compiling and linking it for use on a new -Y2K-compliant system, such as a new version of an old, -non-Y2K-compliant, system. - - Currently, information on Y2K and related issues is being maintained -at `http://www.gnu.org/software/year2000-list.html'. - - See the following for intrinsics known to have potential problems in -these areas on at least some systems: *Note Date Intrinsic::, *Note -IDate Intrinsic (VXT)::. - - The `libg2c' library shipped with any `g77' that warns about -invocation of a non-Y2K-compliant intrinsic has renamed the `EXTERNAL' -procedure names of those intrinsics. This is done so that the `libg2c' -implementations of these intrinsics cannot be directly linked to as -`EXTERNAL' names (which normally would avoid the non-Y2K-intrinsic -warning). - - The renamed forms of the `EXTERNAL' names of these renamed procedures -may be linked to by appending the string `_y2kbug' to the name of the -procedure in the source code. For example: - - CHARACTER*20 STR - INTEGER YY, MM, DD - EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG - CALL DATE_Y2KBUG (STR) - CALL VXTIDATE_Y2KBUG (MM, DD, YY) - - (Note that the `EXTERNAL' statement is not actually required, since -the modified names are not recognized as intrinsics by the current -version of `g77'. But it is shown in this specific case, for purposes -of illustration.) - - The renaming of `EXTERNAL' procedure names of these intrinsics -causes unresolved references at link time. For example, `EXTERNAL -DATE; CALL DATE(STR)' is normally compiled by `g77' as, in C, -`date_(&str, 20);'. This, in turn, links to the `date_' procedure in -the `libE77' portion of `libg2c', which purposely calls a nonexistent -procedure named `G77_date_y2kbuggy_0'. The resulting link-time error -is designed, via this name, to encourage the programmer to look up the -index entries to this portion of the `g77' documentation. - - Generally, we recommend that the `EXTERNAL' method of invoking -procedures in `libg2c' _not_ be used. When used, some of the -correctness checking normally performed by `g77' is skipped. - - In particular, it is probably better to use the `INTRINSIC' method -of invoking non-Y2K-compliant procedures, so anyone compiling the code -can quickly notice the potential Y2K problems (via the warnings -printing by `g77') without having to even look at the code itself. - - If there are problems linking `libg2c' to code compiled by `g77' -that involve the string `y2kbug', and these are not explained above, -that probably indicates that a version of `libg2c' older than `g77' is -being linked to, or that the new library is being linked to code -compiled by an older version of `g77'. - - That's because, as of the version that warns about non-Y2K-compliant -intrinsic invocation, `g77' references the `libg2c' implementations of -those intrinsics using new names, containing the string `y2kbug'. - - So, linking newly-compiled code (invoking one of the intrinsics in -question) to an old library might yield an unresolved reference to -`G77_date_y2kbug_0'. (The old library calls it `G77_date_0'.) - - Similarly, linking previously-compiled code to a new library might -yield an unresolved reference to `G77_vxtidate_0'. (The new library -calls it `G77_vxtidate_y2kbug_0'.) - - The proper fix for the above problems is to obtain the latest -release of `g77' and related products (including `libg2c') and install -them on all systems, then recompile, relink, and install (as -appropriate) all existing Fortran programs. - - (Normally, this sort of renaming is steadfastly avoided. In this -case, however, it seems more important to highlight potential Y2K -problems than to ease the transition of potentially non-Y2K-compliant -code to new versions of `g77' and `libg2c'.) - - -File: g77.info, Node: Array Size, Next: Character-variable Length, Prev: Year 2000 (Y2K) Problems, Up: Run-time Environment Limits - -Array Size ----------- - - Currently, `g77' uses the default `INTEGER' type for array indexes, -which limits the sizes of single-dimension arrays on systems offering a -larger address space than can be addressed by that type. (That `g77' -puts all arrays in memory could be considered another limitation--it -could use large temporary files--but that decision is left to the -programmer as an implementation choice by most Fortran implementations.) - - It is not yet clear whether this limitation never, sometimes, or -always applies to the sizes of multiple-dimension arrays as a whole. - - For example, on a system with 64-bit addresses and 32-bit default -`INTEGER', an array with a size greater than can be addressed by a -32-bit offset can be declared using multiple dimensions. Such an array -is therefore larger than a single-dimension array can be, on the same -system. - - Whether large multiple-dimension arrays are reliably supported -depends mostly on the `gcc' back end (code generator) used by `g77', -and has not yet been fully investigated. - - -File: g77.info, Node: Character-variable Length, Next: Year 10000 (Y10K) Problems, Prev: Array Size, Up: Run-time Environment Limits - -Character-variable Length -------------------------- - - Currently, `g77' uses the default `INTEGER' type for the lengths of -`CHARACTER' variables and array elements. - - This means that, for example, a system with a 64-bit address space -and a 32-bit default `INTEGER' type does not, under `g77', support a -`CHARACTER*N' declaration where N is greater than 2147483647. - - -File: g77.info, Node: Year 10000 (Y10K) Problems, Prev: Character-variable Length, Up: Run-time Environment Limits - -Year 10000 (Y10K) Problems --------------------------- - - Most intrinsics returning, or computing values based on, date -information are prone to Year-10000 (Y10K) problems, due to supporting -only 4 digits for the year. - - See the following for examples: *Note FDate Intrinsic (function)::, -*Note FDate Intrinsic (subroutine)::, *Note IDate Intrinsic (UNIX)::, -*Note Time Intrinsic (VXT)::, *Note Date_and_Time Intrinsic::. - - -File: g77.info, Node: Compiler Types, Next: Compiler Constants, Prev: Run-time Environment Limits, Up: Compiler - -Compiler Types -============== - - Fortran implementations have a fair amount of freedom given them by -the standard as far as how much storage space is used and how much -precision and range is offered by the various types such as -`LOGICAL(KIND=1)', `INTEGER(KIND=1)', `REAL(KIND=1)', `REAL(KIND=2)', -`COMPLEX(KIND=1)', and `CHARACTER'. Further, many compilers offer -so-called `*N' notation, but the interpretation of N varies across -compilers and target architectures. - - The standard requires that `LOGICAL(KIND=1)', `INTEGER(KIND=1)', and -`REAL(KIND=1)' occupy the same amount of storage space, and that -`COMPLEX(KIND=1)' and `REAL(KIND=2)' take twice as much storage space -as `REAL(KIND=1)'. Further, it requires that `COMPLEX(KIND=1)' -entities be ordered such that when a `COMPLEX(KIND=1)' variable is -storage-associated (such as via `EQUIVALENCE') with a two-element -`REAL(KIND=1)' array named `R', `R(1)' corresponds to the real element -and `R(2)' to the imaginary element of the `COMPLEX(KIND=1)' variable. - - (Few requirements as to precision or ranges of any of these are -placed on the implementation, nor is the relationship of storage sizes -of these types to the `CHARACTER' type specified, by the standard.) - - `g77' follows the above requirements, warning when compiling a -program requires placement of items in memory that contradict the -requirements of the target architecture. (For example, a program can -require placement of a `REAL(KIND=2)' on a boundary that is not an even -multiple of its size, but still an even multiple of the size of a -`REAL(KIND=1)' variable. On some target architectures, using the -canonical mapping of Fortran types to underlying architectural types, -such placement is prohibited by the machine definition or the -Application Binary Interface (ABI) in force for the configuration -defined for building `gcc' and `g77'. `g77' warns about such -situations when it encounters them.) - - `g77' follows consistent rules for configuring the mapping between -Fortran types, including the `*N' notation, and the underlying -architectural types as accessed by a similarly-configured applicable -version of the `gcc' compiler. These rules offer a widely portable, -consistent Fortran/C environment, although they might well conflict -with the expectations of users of Fortran compilers designed and -written for particular architectures. - - These rules are based on the configuration that is in force for the -version of `gcc' built in the same release as `g77' (and which was -therefore used to build both the `g77' compiler components and the -`libg2c' run-time library): - -`REAL(KIND=1)' - Same as `float' type. - -`REAL(KIND=2)' - Same as whatever floating-point type that is twice the size of a - `float'--usually, this is a `double'. - -`INTEGER(KIND=1)' - Same as an integral type that is occupies the same amount of - memory storage as `float'--usually, this is either an `int' or a - `long int'. - -`LOGICAL(KIND=1)' - Same `gcc' type as `INTEGER(KIND=1)'. - -`INTEGER(KIND=2)' - Twice the size, and usually nearly twice the range, as - `INTEGER(KIND=1)'--usually, this is either a `long int' or a `long - long int'. - -`LOGICAL(KIND=2)' - Same `gcc' type as `INTEGER(KIND=2)'. - -`INTEGER(KIND=3)' - Same `gcc' type as signed `char'. - -`LOGICAL(KIND=3)' - Same `gcc' type as `INTEGER(KIND=3)'. - -`INTEGER(KIND=6)' - Twice the size, and usually nearly twice the range, as - `INTEGER(KIND=3)'--usually, this is a `short'. - -`LOGICAL(KIND=6)' - Same `gcc' type as `INTEGER(KIND=6)'. - -`COMPLEX(KIND=1)' - Two `REAL(KIND=1)' scalars (one for the real part followed by one - for the imaginary part). - -`COMPLEX(KIND=2)' - Two `REAL(KIND=2)' scalars. - -`NUMERIC-TYPE*N' - (Where NUMERIC-TYPE is any type other than `CHARACTER'.) Same as - whatever `gcc' type occupies N times the storage space of a `gcc' - `char' item. - -`DOUBLE PRECISION' - Same as `REAL(KIND=2)'. - -`DOUBLE COMPLEX' - Same as `COMPLEX(KIND=2)'. - - Note that the above are proposed correspondences and might change in -future versions of `g77'--avoid writing code depending on them. - - Other types supported by `g77' are derived from gcc types such as -`char', `short', `int', `long int', `long long int', `long double', and -so on. That is, whatever types `gcc' already supports, `g77' supports -now or probably will support in a future version. The rules for the -`NUMERIC-TYPE*N' notation apply to these types, and new values for -`NUMERIC-TYPE(KIND=N)' will be assigned in a way that encourages -clarity, consistency, and portability. - - -File: g77.info, Node: Compiler Constants, Next: Compiler Intrinsics, Prev: Compiler Types, Up: Compiler - -Compiler Constants -================== - - `g77' strictly assigns types to _all_ constants not documented as -"typeless" (typeless constants including `'1'Z', for example). Many -other Fortran compilers attempt to assign types to typed constants -based on their context. This results in hard-to-find bugs, nonportable -code, and is not in the spirit (though it strictly follows the letter) -of the 77 and 90 standards. - - `g77' might offer, in a future release, explicit constructs by which -a wider variety of typeless constants may be specified, and/or -user-requested warnings indicating places where `g77' might differ from -how other compilers assign types to constants. - - *Note Context-Sensitive Constants::, for more information on this -issue. - - -File: g77.info, Node: Compiler Intrinsics, Prev: Compiler Constants, Up: Compiler - -Compiler Intrinsics -=================== - - `g77' offers an ever-widening set of intrinsics. Currently these -all are procedures (functions and subroutines). - - Some of these intrinsics are unimplemented, but their names reserved -to reduce future problems with existing code as they are implemented. -Others are implemented as part of the GNU Fortran language, while yet -others are provided for compatibility with other dialects of Fortran -but are not part of the GNU Fortran language. - - To manage these distinctions, `g77' provides intrinsic _groups_, a -facility that is simply an extension of the intrinsic groups provided -by the GNU Fortran language. - -* Menu: - -* Intrinsic Groups:: How intrinsics are grouped for easy management. -* Other Intrinsics:: Intrinsics other than those in the GNU - Fortran language. - - -File: g77.info, Node: Intrinsic Groups, Next: Other Intrinsics, Up: Compiler Intrinsics - -Intrinsic Groups ----------------- - - A given specific intrinsic belongs in one or more groups. Each -group is deleted, disabled, hidden, or enabled by default or a -command-line option. The meaning of each term follows. - -Deleted - No intrinsics are recognized as belonging to that group. - -Disabled - Intrinsics are recognized as belonging to the group, but - references to them (other than via the `INTRINSIC' statement) are - disallowed through that group. - -Hidden - Intrinsics in that group are recognized and enabled (if - implemented) _only_ if the first mention of the actual name of an - intrinsic in a program unit is in an `INTRINSIC' statement. - -Enabled - Intrinsics in that group are recognized and enabled (if - implemented). - - The distinction between deleting and disabling a group is illustrated -by the following example. Assume intrinsic `FOO' belongs only to group -`FGR'. If group `FGR' is deleted, the following program unit will -successfully compile, because `FOO()' will be seen as a reference to an -external function named `FOO': - - PRINT *, FOO() - END - -If group `FGR' is disabled, compiling the above program will produce -diagnostics, either because the `FOO' intrinsic is improperly invoked -or, if properly invoked, it is not enabled. To change the above -program so it references an external function `FOO' instead of the -disabled `FOO' intrinsic, add the following line to the top: - - EXTERNAL FOO - -So, deleting a group tells `g77' to pretend as though the intrinsics in -that group do not exist at all, whereas disabling it tells `g77' to -recognize them as (disabled) intrinsics in intrinsic-like contexts. - - Hiding a group is like enabling it, but the intrinsic must be first -named in an `INTRINSIC' statement to be considered a reference to the -intrinsic rather than to an external procedure. This might be the -"safest" way to treat a new group of intrinsics when compiling old -code, because it allows the old code to be generally written as if -those new intrinsics never existed, but to be changed to use them by -inserting `INTRINSIC' statements in the appropriate places. However, -it should be the goal of development to use `EXTERNAL' for all names of -external procedures that might be intrinsic names. - - If an intrinsic is in more than one group, it is enabled if any of -its containing groups are enabled; if not so enabled, it is hidden if -any of its containing groups are hidden; if not so hidden, it is -disabled if any of its containing groups are disabled; if not so -disabled, it is deleted. This extra complication is necessary because -some intrinsics, such as `IBITS', belong to more than one group, and -hence should be enabled if any of the groups to which they belong are -enabled, and so on. - - The groups are: - -`badu77' - UNIX intrinsics having inappropriate forms (usually functions that - have intended side effects). - -`gnu' - Intrinsics the GNU Fortran language supports that are extensions to - the Fortran standards (77 and 90). - -`f2c' - Intrinsics supported by AT&T's `f2c' converter and/or `libf2c'. - -`f90' - Fortran 90 intrinsics. - -`mil' - MIL-STD 1753 intrinsics (`MVBITS', `IAND', `BTEST', and so on). - -`unix' - UNIX intrinsics (`IARGC', `EXIT', `ERF', and so on). - -`vxt' - VAX/VMS FORTRAN (current as of v4) intrinsics. -