Go to the first, previous, next, last section, table of contents.

Diagnostics

Some diagnostics produced by g77 require sufficient explanation that the explanations are given below, and the diagnostics themselves identify the appropriate explanation.

Identification uses the GNU Info format--specifically, the info command that displays the explanation is given within square brackets in the diagnostic. For example:

foo.f:5: Invalid statement [info -f g77 M FOOEY]

More details about the above diagnostic is found in the g77 Info documentation, menu item `M', submenu item `FOOEY', which is displayed by typing the UNIX command `info -f g77 M FOOEY'.

Other Info readers, such as EMACS, may be just as easily used to display the pertinent node. In the above example, `g77' is the Info document name, `M' is the top-level menu item to select, and, in that node (named `Diagnostics', the name of this chapter, which is the very text you're reading now), `FOOEY' is the menu item to select.

In this printed version of the g77 manual, the above example points to a section, below, entitled `FOOEY'---though, of course, as the above is just a sample, no such section exists.

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:

The result of intrinsic is expected (by the original programmer) to be REAL(KIND=2) (the Fortran 90 interpretation) if:

Once you have determined whether a particular invocation of intrinsic expects the Fortran 90 interpretation, you can:

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:

See section 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!

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.

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.

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:

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.

LINKFAIL

If the above command failed due to an unresolved reference
to strtoul, _strtoul, bsearch, _bsearch, or similar, see
[info -f g77 M LINKFAIL] (a node in the g77 documentation)
for information on what causes this, how to work around
the problem by editing ${srcdir}/proj.c, and what else to do.

See section Missing strtoul or bsearch, for more information on this problem, which occurs only in releases of g77 based on gcc. (It does not occur in egcs.)

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.

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.

See section Year 2000 (Y2K) Problems.


Go to the first, previous, next, last section, table of contents.