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:
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.
-ffree-formwas 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
you are looking at fixed-form code.
Comment lines are indicated by the letter
C or the symbol
* in column 1.
(Some code uses
/* 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
See Source Form, for more information.
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
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.
C in column 1 with a space
is the proper change to make, to ensure the
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.
See Source Form, for more information.
A source file containing lines beginning with
#if, and so on is likely one that
If the file's suffix is
the file normally will be compiled without preprocessing
Change the file's suffix from
(or, on systems with case-insensitive file names,
g77 compiles files with such names with
Or, learn how to use
-x option to specify
f77-cpp-input for Fortran files that
See Options Controlling the Kind of Output.
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.
See Options Controlling the Kind of Output, for suggestions about how to use, and not use, preprocessing for Fortran code.