+++ /dev/null
-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 (<craig@jcb-sc.com>). Inspired by
-a first pass at translating `g77-0.5.16/f/DOC' that was contributed to
-Craig by David Ronis (<ronis@onsager.chem.mcgill.ca>).
-
-\1f
-File: g77.info, Node: CMPAMBIG, Next: EXPIMP, Up: Diagnostics
-
-`CMPAMBIG'
-==========
-
- Ambiguous use of intrinsic INTRINSIC ...
-
- The type of the argument to the invocation of the INTRINSIC
-intrinsic is a `COMPLEX' type other than `COMPLEX(KIND=1)'. Typically,
-it is `COMPLEX(KIND=2)', also known as `DOUBLE COMPLEX'.
-
- The interpretation of this invocation depends on the particular
-dialect of Fortran for which the code was written. Some dialects
-convert the real part of the argument to `REAL(KIND=1)', thus losing
-precision; other dialects, and Fortran 90, do no such conversion.
-
- So, GNU Fortran rejects such invocations except under certain
-circumstances, to avoid making an incorrect assumption that results in
-generating the wrong code.
-
- To determine the dialect of the program unit, perhaps even whether
-that particular invocation is properly coded, determine how the result
-of the intrinsic is used.
-
- The result of INTRINSIC is expected (by the original programmer) to
-be `REAL(KIND=1)' (the non-Fortran-90 interpretation) if:
-
- * It is passed as an argument to a procedure that explicitly or
- implicitly declares that argument `REAL(KIND=1)'.
-
- For example, a procedure with no `DOUBLE PRECISION' or `IMPLICIT
- DOUBLE PRECISION' statement specifying the dummy argument
- corresponding to an actual argument of `REAL(Z)', where `Z' is
- declared `DOUBLE COMPLEX', strongly suggests that the programmer
- expected `REAL(Z)' to return `REAL(KIND=1)' instead of
- `REAL(KIND=2)'.
-
- * It is used in a context that would otherwise not include any
- `REAL(KIND=2)' but where treating the INTRINSIC invocation as
- `REAL(KIND=2)' would result in unnecessary promotions and
- (typically) more expensive operations on the wider type.
-
- For example:
-
- DOUBLE COMPLEX Z
- ...
- R(1) = T * REAL(Z)
-
- The above example suggests the programmer expected the real part
- of `Z' to be converted to `REAL(KIND=1)' before being multiplied
- by `T' (presumed, along with `R' above, to be type `REAL(KIND=1)').
-
- Otherwise, the conversion would have to be delayed until after the
- multiplication, requiring not only an extra conversion (of `T' to
- `REAL(KIND=2)'), but a (typically) more expensive multiplication
- (a double-precision multiplication instead of a single-precision
- one).
-
- The result of INTRINSIC is expected (by the original programmer) to
-be `REAL(KIND=2)' (the Fortran 90 interpretation) if:
-
- * It is passed as an argument to a procedure that explicitly or
- implicitly declares that argument `REAL(KIND=2)'.
-
- For example, a procedure specifying a `DOUBLE PRECISION' dummy
- argument corresponding to an actual argument of `REAL(Z)', where
- `Z' is declared `DOUBLE COMPLEX', strongly suggests that the
- programmer expected `REAL(Z)' to return `REAL(KIND=2)' instead of
- `REAL(KIND=1)'.
-
- * It is used in an expression context that includes other
- `REAL(KIND=2)' operands, or is assigned to a `REAL(KIND=2)'
- variable or array element.
-
- For example:
-
- DOUBLE COMPLEX Z
- DOUBLE PRECISION R, T
- ...
- R(1) = T * REAL(Z)
-
- The above example suggests the programmer expected the real part
- of `Z' to _not_ be converted to `REAL(KIND=1)' by the `REAL()'
- intrinsic.
-
- Otherwise, the conversion would have to be immediately followed by
- a conversion back to `REAL(KIND=2)', losing the original, full
- precision of the real part of `Z', before being multiplied by `T'.
-
- Once you have determined whether a particular invocation of INTRINSIC
-expects the Fortran 90 interpretation, you can:
-
- * Change it to `DBLE(EXPR)' (if INTRINSIC is `REAL') or
- `DIMAG(EXPR)' (if INTRINSIC is `AIMAG') if it expected the Fortran
- 90 interpretation.
-
- This assumes EXPR is `COMPLEX(KIND=2)'--if it is some other type,
- such as `COMPLEX*32', you should use the appropriate intrinsic,
- such as the one to convert to `REAL*16' (perhaps `DBLEQ()' in
- place of `DBLE()', and `QIMAG()' in place of `DIMAG()').
-
- * Change it to `REAL(INTRINSIC(EXPR))', otherwise. This converts to
- `REAL(KIND=1)' in all working Fortran compilers.
-
- If you don't want to change the code, and you are certain that all
-ambiguous invocations of INTRINSIC in the source file have the same
-expectation regarding interpretation, you can:
-
- * Compile with the `g77' option `-ff90', to enable the Fortran 90
- interpretation.
-
- * Compile with the `g77' options `-fno-f90 -fugly-complex', to
- enable the non-Fortran-90 interpretations.
-
- *Note REAL() and AIMAG() of Complex::, for more information on this
-issue.
-
- Note: If the above suggestions don't produce enough evidence as to
-whether a particular program expects the Fortran 90 interpretation of
-this ambiguous invocation of INTRINSIC, there is one more thing you can
-try.
-
- If you have access to most or all the compilers used on the program
-to create successfully tested and deployed executables, read the
-documentation for, and _also_ test out, each compiler to determine how
-it treats the INTRINSIC intrinsic in this case. (If all the compilers
-don't agree on an interpretation, there might be lurking bugs in the
-deployed versions of the program.)
-
- The following sample program might help:
-
- PROGRAM JCB003
- C
- C Written by James Craig Burley 1997-02-23.
- C
- C Determine how compilers handle non-standard REAL
- C and AIMAG on DOUBLE COMPLEX operands.
- C
- DOUBLE COMPLEX Z
- REAL R
- Z = (3.3D0, 4.4D0)
- R = Z
- CALL DUMDUM(Z, R)
- R = REAL(Z) - R
- IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
- IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
- R = 4.4D0
- CALL DUMDUM(Z, R)
- R = AIMAG(Z) - R
- IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
- IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
- END
- C
- C Just to make sure compiler doesn't use naive flow
- C analysis to optimize away careful work above,
- C which might invalidate results....
- C
- SUBROUTINE DUMDUM(Z, R)
- DOUBLE COMPLEX Z
- REAL R
- END
-
- If the above program prints contradictory results on a particular
-compiler, run away!
-
-\1f
-File: g77.info, Node: EXPIMP, Next: INTGLOB, Prev: CMPAMBIG, Up: Diagnostics
-
-`EXPIMP'
-========
-
- Intrinsic INTRINSIC referenced ...
-
- The INTRINSIC is explicitly declared in one program unit in the
-source file and implicitly used as an intrinsic in another program unit
-in the same source file.
-
- This diagnostic is designed to catch cases where a program might
-depend on using the name INTRINSIC as an intrinsic in one program unit
-and as a global name (such as the name of a subroutine or function) in
-another, but `g77' recognizes the name as an intrinsic in both cases.
-
- After verifying that the program unit making implicit use of the
-intrinsic is indeed written expecting the intrinsic, add an `INTRINSIC
-INTRINSIC' statement to that program unit to prevent this warning.
-
- This and related warnings are disabled by using the `-Wno-globals'
-option when compiling.
-
- Note that this warning is not issued for standard intrinsics.
-Standard intrinsics include those described in the FORTRAN 77 standard
-and, if `-ff90' is specified, those described in the Fortran 90
-standard. Such intrinsics are not as likely to be confused with user
-procedures as intrinsics provided as extensions to the standard by
-`g77'.
-
-\1f
-File: g77.info, Node: INTGLOB, Next: LEX, Prev: EXPIMP, Up: Diagnostics
-
-`INTGLOB'
-=========
-
- Same name `INTRINSIC' given ...
-
- The name INTRINSIC is used for a global entity (a common block or a
-program unit) in one program unit and implicitly used as an intrinsic
-in another program unit.
-
- This diagnostic is designed to catch cases where a program intends
-to use a name entirely as a global name, but `g77' recognizes the name
-as an intrinsic in the program unit that references the name, a
-situation that would likely produce incorrect code.
-
- For example:
-
- INTEGER FUNCTION TIME()
- ...
- END
- ...
- PROGRAM SAMP
- INTEGER TIME
- PRINT *, 'Time is ', TIME()
- END
-
- The above example defines a program unit named `TIME', but the
-reference to `TIME' in the main program unit `SAMP' is normally treated
-by `g77' as a reference to the intrinsic `TIME()' (unless a
-command-line option that prevents such treatment has been specified).
-
- As a result, the program `SAMP' will _not_ invoke the `TIME'
-function in the same source file.
-
- Since `g77' recognizes `libU77' procedures as intrinsics, and since
-some existing code uses the same names for its own procedures as used
-by some `libU77' procedures, this situation is expected to arise often
-enough to make this sort of warning worth issuing.
-
- After verifying that the program unit making implicit use of the
-intrinsic is indeed written expecting the intrinsic, add an `INTRINSIC
-INTRINSIC' statement to that program unit to prevent this warning.
-
- Or, if you believe the program unit is designed to invoke the
-program-defined procedure instead of the intrinsic (as recognized by
-`g77'), add an `EXTERNAL INTRINSIC' statement to the program unit that
-references the name to prevent this warning.
-
- This and related warnings are disabled by using the `-Wno-globals'
-option when compiling.
-
- Note that this warning is not issued for standard intrinsics.
-Standard intrinsics include those described in the FORTRAN 77 standard
-and, if `-ff90' is specified, those described in the Fortran 90
-standard. Such intrinsics are not as likely to be confused with user
-procedures as intrinsics provided as extensions to the standard by
-`g77'.
-
-\1f
-File: g77.info, Node: LEX, Next: GLOBALS, Prev: INTGLOB, Up: Diagnostics
-
-`LEX'
-=====
-
- Unrecognized character ...
- Invalid first character ...
- Line too long ...
- Non-numeric character ...
- Continuation indicator ...
- Label at ... invalid with continuation line indicator ...
- Character constant ...
- Continuation line ...
- Statement at ... begins with invalid token
-
- Although the diagnostics identify specific problems, they can be
-produced when general problems such as the following occur:
-
- * The source file contains something other than Fortran code.
-
- If the code in the file does not look like many of the examples
- elsewhere in this document, it might not be Fortran code. (Note
- that Fortran code often is written in lower case letters, while
- the examples in this document use upper case letters, for
- stylistic reasons.)
-
- For example, if the file contains lots of strange-looking
- characters, it might be APL source code; if it contains lots of
- parentheses, it might be Lisp source code; if it contains lots of
- bugs, it might be C++ source code.
-
- * The source file contains free-form Fortran code, but `-ffree-form'
- was not specified on the command line to compile it.
-
- Free form is a newer form for Fortran code. The older, classic
- form is called fixed form.
-
- Fixed-form code is visually fairly distinctive, because numerical
- labels and comments are all that appear in the first five columns
- of a line, the sixth column is reserved to denote continuation
- lines, and actual statements start at or beyond column 7. Spaces
- generally are not significant, so if you see statements such as
- `REALX,Y' and `DO10I=1,100', you are looking at fixed-form code.
- Comment lines are indicated by the letter `C' or the symbol `*' in
- column 1. (Some code uses `!' or `/*' to begin in-line comments,
- which many compilers support.)
-
- Free-form code is distinguished from fixed-form source primarily
- by the fact that statements may start anywhere. (If lots of
- statements start in columns 1 through 6, that's a strong indicator
- of free-form source.) Consecutive keywords must be separated by
- spaces, so `REALX,Y' is not valid, while `REAL X,Y' is. There are
- no comment lines per se, but `!' starts a comment anywhere in a
- line (other than within a character or Hollerith constant).
-
- *Note Source Form::, for more information.
-
- * The source file is in fixed form and has been edited without
- sensitivity to the column requirements.
-
- Statements in fixed-form code must be entirely contained within
- columns 7 through 72 on a given line. Starting them "early" is
- more likely to result in diagnostics than finishing them "late",
- though both kinds of errors are often caught at compile time.
-
- For example, if the following code fragment is edited by following
- the commented instructions literally, the result, shown afterward,
- would produce a diagnostic when compiled:
-
- C On XYZZY systems, remove "C" on next line:
- C CALL XYZZY_RESET
-
- The result of editing the above line might be:
-
- C On XYZZY systems, remove "C" on next line:
- CALL XYZZY_RESET
-
- However, that leaves the first `C' in the `CALL' statement in
- column 6, making it a comment line, which is not really what the
- author intended, and which is likely to result in one of the
- above-listed diagnostics.
-
- _Replacing_ the `C' in column 1 with a space is the proper change
- to make, to ensure the `CALL' keyword starts in or after column 7.
-
- Another common mistake like this is to forget that fixed-form
- source lines are significant through only column 72, and that,
- normally, any text beyond column 72 is ignored or is diagnosed at
- compile time.
-
- *Note Source Form::, for more information.
-
- * The source file requires preprocessing, and the preprocessing is
- not being specified at compile time.
-
- A source file containing lines beginning with `#define',
- `#include', `#if', and so on is likely one that requires
- preprocessing.
-
- If the file's suffix is `.f', `.for', or `.FOR', the file normally
- will be compiled _without_ preprocessing by `g77'.
-
- Change the file's suffix from `.f' to `.F' (or, on systems with
- case-insensitive file names, to `.fpp' or `.FPP'), from `.for' to
- `.fpp', or from `.FOR' to `.FPP'. `g77' compiles files with such
- names _with_ preprocessing.
-
- Or, learn how to use `gcc''s `-x' option to specify the language
- `f77-cpp-input' for Fortran files that require preprocessing.
- *Note Options Controlling the Kind of Output: (gcc)Overall Options.
-
- * The source file is preprocessed, and the results of preprocessing
- result in syntactic errors that are not necessarily obvious to
- someone examining the source file itself.
-
- Examples of errors resulting from preprocessor macro expansion
- include exceeding the line-length limit, improperly starting,
- terminating, or incorporating the apostrophe or double-quote in a
- character constant, improperly forming a Hollerith constant, and
- so on.
-
- *Note Options Controlling the Kind of Output: Overall Options, for
- suggestions about how to use, and not use, preprocessing for
- Fortran code.
-
-\1f
-File: g77.info, Node: GLOBALS, Next: LINKFAIL, Prev: LEX, Up: Diagnostics
-
-`GLOBALS'
-=========
-
- Global name NAME defined at ... already defined...
- Global name NAME at ... has different type...
- Too many arguments passed to NAME at ...
- Too few arguments passed to NAME at ...
- Argument #N of NAME is ...
-
- These messages all identify disagreements about the global procedure
-named NAME among different program units (usually including NAME
-itself).
-
- Whether a particular disagreement is reported as a warning or an
-error can depend on the relative order of the disagreeing portions of
-the source file.
-
- Disagreements between a procedure invocation and the _subsequent_
-procedure itself are, usually, diagnosed as errors when the procedure
-itself _precedes_ the invocation. Other disagreements are diagnosed
-via warnings.
-
- This distinction, between warnings and errors, is due primarily to
-the present tendency of the `gcc' back end to inline only those
-procedure invocations that are _preceded_ by the corresponding
-procedure definitions. If the `gcc' back end is changed to inline
-"forward references", in which invocations precede definitions, the
-`g77' front end will be changed to treat both orderings as errors,
-accordingly.
-
- The sorts of disagreements that are diagnosed by `g77' include
-whether a procedure is a subroutine or function; if it is a function,
-the type of the return value of the procedure; the number of arguments
-the procedure accepts; and the type of each argument.
-
- Disagreements regarding global names among program units in a
-Fortran program _should_ be fixed in the code itself. However, if that
-is not immediately practical, and the code has been working for some
-time, it is possible it will work when compiled with the `-fno-globals'
-option.
-
- The `-fno-globals' option causes these diagnostics to all be warnings
-and disables all inlining of references to global procedures (to avoid
-subsequent compiler crashes and bad-code generation). Use of the
-`-Wno-globals' option as well as `-fno-globals' suppresses all of these
-diagnostics. (`-Wno-globals' by itself disables only the warnings, not
-the errors.)
-
- After using `-fno-globals' to work around these problems, it is wise
-to stop using that option and address them by fixing the Fortran code,
-because such problems, while they might not actually result in bugs on
-some systems, indicate that the code is not as portable as it could be.
-In particular, the code might appear to work on a particular system,
-but have bugs that affect the reliability of the data without
-exhibiting any other outward manifestations of the bugs.
-
-\1f
-File: g77.info, Node: LINKFAIL, Next: Y2KBAD, Prev: GLOBALS, Up: Diagnostics
-
-`LINKFAIL'
-==========
-
-On AIX 4.1, `g77' might not build with the native (non-GNU) tools due
-to a linker bug in coping with the `-bbigtoc' option which leads to a
-`Relocation overflow' error. The GNU linker is not recommended on
-current AIX versions, though; it was developed under a now-unsupported
-version. This bug is said to be fixed by `update PTF U455193 for APAR
-IX75823'.
-
- Compiling with `-mminimal-toc' might solve this problem, e.g. by
-adding
- BOOT_CFLAGS='-mminimal-toc -O2 -g'
- to the `make bootstrap' command line.
-
-\1f
-File: g77.info, Node: Y2KBAD, Prev: LINKFAIL, Up: Diagnostics
-
-`Y2KBAD'
-========
-
- Intrinsic `NAME', invoked at (^), known to be non-Y2K-compliant...
-
- This diagnostic indicates that the specific intrinsic invoked by the
-name NAME is known to have an interface that is not Year-2000 (Y2K)
-compliant.
-
- *Note Year 2000 (Y2K) Problems::.
-
projects / msp430-gcc.git / blobdiff