GNU Info

(g77-295.info)LEX

---

Next: GLOBALS Prev: INTGLOB Up: Diagnostics

---

Enter node , (file) or (file)node

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

   * 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, for
     suggestions about how to use, and not use, preprocessing for
     Fortran code.