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: 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!  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'.  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'.  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.  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.  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.  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::.