This is Info file f/g77.info, produced by Makeinfo version 1.68 from the input file ./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 (). Inspired by a first pass at translating `g77-0.5.16/f/DOC' that was contributed to Craig by David Ronis (). 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.