This is Info file f/g77.info, produced by Makeinfo version 1.68 from
the input file ../../gcc/f/g77.texi.

   This file explains how to use the GNU Fortran system.

   Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA

   Copyright (C) 1995-1997 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

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

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* g77: (g77).                  The GNU Fortran compiler.
END-INFO-DIR-ENTRY


File: g77.info,  Node: Projects,  Next: Diagnostics,  Prev: Adding Options,  Up: Top

Projects
********

   If you want to contribute to `g77' by doing research, design,
specification, documentation, coding, or testing, the following
information should give you some ideas.  More relevant information
might be available from `ftp://alpha.gnu.org/gnu/g77/projects/'.

* Menu:

* Efficiency::               Make `g77' itself compile code faster.
* Better Optimization::      Teach `g77' to generate faster code.
* Simplify Porting::         Make `g77' easier to configure, build,
                             and install.
* More Extensions::          Features many users won't know to ask for.
* Machine Model::            `g77' should better leverage `gcc'.
* Internals Documentation::  Make maintenance easier.
* Internals Improvements::   Make internals more robust.
* Better Diagnostics::       Make using `g77' on new code easier.


File: g77.info,  Node: Efficiency,  Next: Better Optimization,  Up: Projects

Improve Efficiency
==================

   Don't bother doing any performance analysis until most of the
following items are taken care of, because there's no question they
represent serious space/time problems, although some of them show up
only given certain kinds of (popular) input.

   * Improve `malloc' package and its uses to specify more info about
     memory pools and, where feasible, use obstacks to implement them.

   * Skip over uninitialized portions of aggregate areas (arrays,
     `COMMON' areas, `EQUIVALENCE' areas) so zeros need not be output.
     This would reduce memory usage for large initialized aggregate
     areas, even ones with only one initialized element.

     As of version 0.5.18, a portion of this item has already been
     accomplished.

   * Prescan the statement (in `sta.c') so that the nature of the
     statement is determined as much as possible by looking entirely at
     its form, and not looking at any context (previous statements,
     including types of symbols).  This would allow ripping out of the
     statement-confirmation, symbol retraction/confirmation, and
     diagnostic inhibition mechanisms.  Plus, it would result in
     much-improved diagnostics.  For example, `CALL
     some-intrinsic(...)', where the intrinsic is not a subroutine
     intrinsic, would result actual error instead of the
     unimplemented-statement catch-all.

   * Throughout `g77', don't pass line/column pairs where a simple
     `ffewhere' type, which points to the error as much as is desired
     by the configuration, will do, and don't pass `ffelexToken' types
     where a simple `ffewhere' type will do.  Then, allow new default
     configuration of `ffewhere' such that the source line text is not
     preserved, and leave it to things like Emacs' next-error function
     to point to them (now that `next-error' supports column, or,
     perhaps, character-offset, numbers).  The change in calling
     sequences should improve performance somewhat, as should not
     having to save source lines.  (Whether this whole item will
     improve performance is questionable, but it should improve
     maintainability.)

   * Handle `DATA (A(I),I=1,1000000)/1000000*2/' more efficiently,
     especially as regards the assembly output.  Some of this might
     require improving the back end, but lots of improvement in
     space/time required in `g77' itself can be fairly easily obtained
     without touching the back end.  Maybe type-conversion, where
     necessary, can be speeded up as well in cases like the one shown
     (converting the `2' into `2.').

   * If analysis shows it to be worthwhile, optimize `lex.c'.

   * Consider redesigning `lex.c' to not need any feedback during
     tokenization, by keeping track of enough parse state on its own.


File: g77.info,  Node: Better Optimization,  Next: Simplify Porting,  Prev: Efficiency,  Up: Projects

Better Optimization
===================

   Much of this work should be put off until after `g77' has all the
features necessary for its widespread acceptance as a useful F77
compiler.  However, perhaps this work can be done in parallel during
the feature-adding work.

   * Do the equivalent of the trick of putting `extern inline' in front
     of every function definition in `libg2c' and #include'ing the
     resulting file in `f2c'+`gcc'--that is, inline all
     run-time-library functions that are at all worth inlining.  (Some
     of this has already been done, such as for integral
     exponentiation.)

   * When doing `CHAR_VAR = CHAR_FUNC(...)', and it's clear that types
     line up and `CHAR_VAR' is addressable or not a `VAR_DECL', make
     `CHAR_VAR', not a temporary, be the receiver for `CHAR_FUNC'.
     (This is now done for `COMPLEX' variables.)

   * Design and implement Fortran-specific optimizations that don't
     really belong in the back end, or where the front end needs to
     give the back end more info than it currently does.

   * Design and implement a new run-time library interface, with the
     code going into `libgcc' so no special linking is required to link
     Fortran programs using standard language features.  This library
     would speed up lots of things, from I/O (using precompiled formats,
     doing just one, or, at most, very few, calls for arrays or array
     sections, and so on) to general computing (array/section
     implementations of various intrinsics, implementation of commonly
     performed loops that aren't likely to be optimally compiled
     otherwise, etc.).

     Among the important things the library would do are:

        * Be a one-stop-shop-type library, hence shareable and usable
          by all, in that what are now library-build-time options in
          `libg2c' would be moved at least to the `g77' compile phase,
          if not to finer grains (such as choosing how list-directed
          I/O formatting is done by default at `OPEN' time, for
          preconnected units via options or even statements in the main
          program unit, maybe even on a per-I/O basis with appropriate
          pragma-like devices).

   * Probably requiring the new library design, change interface to
     normally have `COMPLEX' functions return their values in the way
     `gcc' would if they were declared `__complex__ float', rather than
     using the mechanism currently used by `CHARACTER' functions
     (whereby the functions are compiled as returning void and their
     first arg is a pointer to where to store the result).  (Don't
     append underscores to external names for `COMPLEX' functions in
     some cases once `g77' uses `gcc' rather than `f2c' calling
     conventions.)

   * Do something useful with `doiter' references where possible.  For
     example, `CALL FOO(I)' cannot modify `I' if within a `DO' loop
     that uses `I' as the iteration variable, and the back end might
     find that info useful in determining whether it needs to read `I'
     back into a register after the call.  (It normally has to do that,
     unless it knows `FOO' never modifies its passed-by-reference
     argument, which is rarely the case for Fortran-77 code.)


File: g77.info,  Node: Simplify Porting,  Next: More Extensions,  Prev: Better Optimization,  Up: Projects

Simplify Porting
================

   Making `g77' easier to configure, port, build, and install, either
as a single-system compiler or as a cross-compiler, would be very
useful.

   * A new library (replacing `libg2c') should improve portability as
     well as produce more optimal code.  Further, `g77' and the new
     library should conspire to simplify naming of externals, such as
     by removing unnecessarily added underscores, and to
     reduce/eliminate the possibility of naming conflicts, while making
     debugger more straightforward.

     Also, it should make multi-language applications more feasible,
     such as by providing Fortran intrinsics that get Fortran unit
     numbers given C `FILE *' descriptors.

   * Possibly related to a new library, `g77' should produce the
     equivalent of a `gcc' `main(argc, argv)' function when it compiles
     a main program unit, instead of compiling something that must be
     called by a library implementation of `main()'.

     This would do many useful things such as provide more flexibility
     in terms of setting up exception handling, not requiring
     programmers to start their debugging sessions with `breakpoint
     MAIN__' followed by `run', and so on.

   * The GBE needs to understand the difference between alignment
     requirements and desires.  For example, on Intel x86 machines,
     `g77' currently imposes overly strict alignment requirements, due
     to the back end, but it would be useful for Fortran and C
     programmers to be able to override these *recommendations* as long
     as they don't violate the actual processor *requirements*.


File: g77.info,  Node: More Extensions,  Next: Machine Model,  Prev: Simplify Porting,  Up: Projects

More Extensions
===============

   These extensions are not the sort of things users ask for "by name",
but they might improve the usability of `g77', and Fortran in general,
in the long run.  Some of these items really pertain to improving `g77'
internals so that some popular extensions can be more easily supported.

   * Look through all the documentation on the GNU Fortran language,
     dialects, compiler, missing features, bugs, and so on.  Many
     mentions of incomplete or missing features are sprinkled
     throughout.  It is not worth repeating them here.

   * Support arbitrary operands for concatenation, even in contexts
     where run-time allocation is required.

   * Consider adding a `NUMERIC' type to designate typeless numeric
     constants, named and unnamed.  The idea is to provide a
     forward-looking, effective replacement for things like the
     old-style `PARAMETER' statement when people really need
     typelessness in a maintainable, portable, clearly documented way.
     Maybe `TYPELESS' would include `CHARACTER', `POINTER', and
     whatever else might come along.  (This is not really a call for
     polymorphism per se, just an ability to express limited, syntactic
     polymorphism.)

   * Support `OPEN(...,KEY=(...),...)'.

   * Support arbitrary file unit numbers, instead of limiting them to 0
     through `MXUNIT-1'.  (This is a `libg2c' issue.)

   * `OPEN(NOSPANBLOCKS,...)' is treated as
     `OPEN(UNIT=NOSPANBLOCKS,...)', so a later `UNIT=' in the first
     example is invalid.  Make sure this is what users of this feature
     would expect.

   * Currently `g77' disallows `READ(1'10)' since it is an obnoxious
     syntax, but supporting it might be pretty easy if needed.  More
     details are needed, such as whether general expressions separated
     by an apostrophe are supported, or maybe the record number can be
     a general expression, and so on.

   * Support `STRUCTURE', `UNION', `MAP', and `RECORD' fully.
     Currently there is no support at all for `%FILL' in `STRUCTURE'
     and related syntax, whereas the rest of the stuff has at least
     some parsing support.  This requires either major changes to
     `libg2c' or its replacement.

   * F90 and `g77' probably disagree about label scoping relative to
     `INTERFACE' and `END INTERFACE', and their contained procedure
     interface bodies (blocks?).

   * `ENTRY' doesn't support F90 `RESULT()' yet, since that was added
     after S8.112.

   * Empty-statement handling (10 ;;CONTINUE;;) probably isn't
     consistent with the final form of the standard (it was vague at
     S8.112).

   * It seems to be an "open" question whether a file, immediately
     after being `OPEN'ed,is positioned at the beginning, the end, or
     wherever--it might be nice to offer an option of opening to
     "undefined" status, requiring an explicit absolute-positioning
     operation to be performed before any other (besides `CLOSE') to
     assist in making applications port to systems (some IBM?) that
     `OPEN' to the end of a file or some such thing.


File: g77.info,  Node: Machine Model,  Next: Internals Documentation,  Prev: More Extensions,  Up: Projects

Machine Model
=============

   This items pertain to generalizing `g77''s view of the machine model
to more fully accept whatever the GBE provides it via its configuration.

   * Switch to using `REAL_VALUE_TYPE' to represent floating-point
     constants exclusively so the target float format need not be
     required.  This means changing the way `g77' handles
     initialization of aggregate areas having more than one type, such
     as `REAL' and `INTEGER', because currently it initializes them as
     if they were arrays of `char' and uses the bit patterns of the
     constants of the various types in them to determine what to stuff
     in elements of the arrays.

   * Rely more and more on back-end info and capabilities, especially
     in the area of constants (where having the `g77' front-end's IL
     just store the appropriate tree nodes containing constants might
     be best).

   * Suite of C and Fortran programs that a user/administrator can run
     on a machine to help determine the configuration for `g77' before
     building and help determine if the compiler works (especially with
     whatever libraries are installed) after building.


File: g77.info,  Node: Internals Documentation,  Next: Internals Improvements,  Prev: Machine Model,  Up: Projects

Internals Documentation
=======================

   Better info on how `g77' works and how to port it is needed.  Much
of this should be done only after the redesign planned for 0.6 is
complete.


File: g77.info,  Node: Internals Improvements,  Next: Better Diagnostics,  Prev: Internals Documentation,  Up: Projects

Internals Improvements
======================

   Some more items that would make `g77' more reliable and easier to
maintain:

   * Generally make expression handling focus more on critical syntax
     stuff, leaving semantics to callers.  For example, anything a
     caller can check, semantically, let it do so, rather than having
     `expr.c' do it.  (Exceptions might include things like diagnosing
     `FOO(I--K:)=BAR' where `FOO' is a `PARAMETER'--if it seems
     important to preserve the left-to-right-in-source order of
     production of diagnostics.)

   * Come up with better naming conventions for `-D' to establish
     requirements to achieve desired implementation dialect via
     `proj.h'.

   * Clean up used tokens and `ffewhere's in `ffeglobal_terminate_1'.

   * Replace `sta.c' `outpooldisp' mechanism with `malloc_pool_use'.

   * Check for `opANY' in more places in `com.c', `std.c', and `ste.c',
     and get rid of the `opCONVERT(opANY)' kludge (after determining if
     there is indeed no real need for it).

   * Utility to read and check `bad.def' messages and their references
     in the code, to make sure calls are consistent with message
     templates.

   * Search and fix `&ffe...' and similar so that `ffe...ptr...' macros
     are available instead (a good argument for wishing this could have
     written all this stuff in C++, perhaps).  On the other hand, it's
     questionable whether this sort of improvement is really necessary,
     given the availability of tools such as Emacs and Perl, which make
     finding any address-taking of structure members easy enough?

   * Some modules truly export the member names of their structures
     (and the structures themselves), maybe fix this, and fix other
     modules that just appear to as well (by appending `_', though it'd
     be ugly and probably not worth the time).

   * Implement C macros `RETURNS(value)' and `SETS(something,value)' in
     `proj.h' and use them throughout `g77' source code (especially in
     the definitions of access macros in `.h' files) so they can be
     tailored to catch code writing into a `RETURNS()' or reading from
     a `SETS()'.

   * Decorate throughout with `const' and other such stuff.

   * All F90 notational derivations in the source code are still based
     on the S8.112 version of the draft standard.  Probably should
     update to the official standard, or put documentation of the rules
     as used in the code...uh...in the code.

   * Some `ffebld_new' calls (those outside of `ffeexpr.c' or inside
     but invoked via paths not involving `ffeexpr_lhs' or
     `ffeexpr_rhs') might be creating things in improper pools, leading
     to such things staying around too long or (doubtful, but possible
     and dangerous) not long enough.

   * Some `ffebld_list_new' (or whatever) calls might not be matched by
     `ffebld_list_bottom' (or whatever) calls, which might someday
     matter.  (It definitely is not a problem just yet.)

   * Probably not doing clean things when we fail to `EQUIVALENCE'
     something due to alignment/mismatch or other problems--they end up
     without `ffestorag' objects, so maybe the backend (and other parts
     of the front end) can notice that and handle like an `opANY' (do
     what it wants, just don't complain or crash).  Most of this seems
     to have been addressed by now, but a code review wouldn't hurt.


File: g77.info,  Node: Better Diagnostics,  Prev: Internals Improvements,  Up: Projects

Better Diagnostics
==================

   These are things users might not ask about, or that need to be
looked into, before worrying about.  Also here are items that involve
reducing unnecessary diagnostic clutter.

   * When `FUNCTION' and `ENTRY' point types disagree (`CHARACTER'
     lengths, type classes, and so on), `ANY'-ize the offending `ENTRY'
     point and any *new* dummies it specifies.

   * Speed up and improve error handling for data when repeat-count is
     specified.  For example, don't output 20 unnecessary messages
     after the first necessary one for:

          INTEGER X(20)
          CONTINUE
          DATA (X(I), J= 1, 20) /20*5/
          END

     (The `CONTINUE' statement ensures the `DATA' statement is
     processed in the context of executable, not specification,
     statements.)


File: g77.info,  Node: Diagnostics,  Next: Index,  Prev: Projects,  Up: Top

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.

* Menu:

* CMPAMBIG::    Ambiguous use of intrinsic.
* EXPIMP::      Intrinsic used explicitly and implicitly.
* INTGLOB::     Intrinsic also used as name of global.
* LEX::         Various lexer messages
* GLOBALS::     Disagreements about globals.
* LINKFAIL::    When linking `f771' fails.


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 Contact via Internet email: burley@gnu.org
     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' or `.for', the file will normally 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 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 gcc: (Using and Porting GNU CC)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).

   These disagreements, if not diagnosed, could result in a compiler
crash if the compiler attempted to inline a reference to NAME within a
calling program unit that disagreed with the NAME program unit
regarding whether the procedure is a subroutine or function, the type
of the return value of the procedure (if it is a function), the number
of arguments the procedure accepts, or the type of each argument.

   Such disagreements *should* be fixed in the Fortran 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 by
`g77' with the `-fno-globals' option.

   The `-fno-globals' option disables these diagnostics, and also
disables all inlining of references to global procedures to avoid
compiler crashes.  The diagnostics are actually produced, but as
warnings, unless the `-Wno-globals' option also is specified.

   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,  Prev: GLOBALS,  Up: Diagnostics

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

   *Note 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.

