home *** CD-ROM | disk | FTP | other *** search
GNU Info File | 1997-09-12 | 39.8 KB | 969 lines
This is Info file g77.info, produced by Makeinfo version 1.68 from the input file 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 (<burley@gnu.ai.mit.edu>). 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 Fortran Programming START-INFO-DIR-ENTRY * g77: (g77). The GNU Fortran compilation system. END-INFO-DIR-ENTRY File: g77.info, Node: Floating-point Exception Handling, Next: Nonportable Conversions, Prev: POSIX Standard, Up: Missing Features Floating-point Exception Handling --------------------------------- The `gcc' backend and, consequently, `g77', currently provides no control over whether or not floating-point exceptions are trapped or ignored. (Ignoring them typically results in NaN values being propagated in systems that conform to IEEE 754.) The behaviour is inherited from the system-dependent startup code. Most systems provide some C-callable mechanism to change this; this can be invoked at startup using `gcc''s `constructor' attribute. For example, just compiling and linking the following C code with your program will turn on exception trapping for the "common" exceptions on an x86-based GNU system: #include <fpu_control.h> void __attribute__ ((constructor)) trapfpe () { (void) __setfpucw (_FPU_DEFAULT & ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM)); } File: g77.info, Node: Nonportable Conversions, Next: Large Automatic Arrays, Prev: Floating-point Exception Handling, Up: Missing Features Nonportable Conversions ----------------------- `g77' doesn't accept some particularly nonportable, silent data-type conversions such as `LOGICAL' to `REAL' (as in `A=.FALSE.', where `A' is type `REAL'), that other compilers might quietly accept. Some of these conversions are accepted by `g77' when the `-fugly' option is specified. Perhaps it should accept more or all of them. File: g77.info, Node: Large Automatic Arrays, Next: Support for Threads, Prev: Nonportable Conversions, Up: Missing Features Large Automatic Arrays ---------------------- Currently, automatic arrays always are allocated on the stack. For situations where the stack cannot be made large enough, `g77' should offer a compiler option that specifies allocation of automatic arrays in heap storage. File: g77.info, Node: Support for Threads, Next: Increasing Precision/Range, Prev: Large Automatic Arrays, Up: Missing Features Support for Threads ------------------- Neither the code produced by `g77' nor the `libf2c' library are thread-safe, nor does `g77' have support for parallel processing (other than the instruction-level parallelism available on some processors). A package such as PVM might help here. File: g77.info, Node: Gracefully Handle Sensible Bad Code, Next: Non-standard Conversions, Prev: Increasing Precision/Range, Up: Missing Features Gracefully Handle Sensible Bad Code ----------------------------------- `g77' generally should continue processing for warnings and recoverable (user) errors whenever possible--that is, it shouldn't gratuitously make bad or useless code. For example: INTRINSIC ZABS CALL FOO(ZABS) END When compiling the above with `-ff2c-intrinsics-disable', `g77' should indeed complain about passing `ZABS', but it still should compile, instead of rejecting the entire `CALL' statement. (Some of this is related to improving the compiler internals to improve how statements are analyzed.) File: g77.info, Node: Non-standard Conversions, Next: Non-standard Intrinsics, Prev: Gracefully Handle Sensible Bad Code, Up: Missing Features Non-standard Conversions ------------------------ `-Wconversion' and related should flag places where non-standard conversions are found. Perhaps much of this would be part of `-Wugly*'. File: g77.info, Node: Non-standard Intrinsics, Next: Modifying DO Variable, Prev: Non-standard Conversions, Up: Missing Features Non-standard Intrinsics ----------------------- `g77' needs a new option, like `-Wintrinsics', to warn about use of non-standard intrinsics without explicit `INTRINSIC' statements for them. This would help find code that might fail silently when ported to another compiler. File: g77.info, Node: Modifying DO Variable, Next: Better Pedantic Compilation, Prev: Non-standard Intrinsics, Up: Missing Features Modifying `DO' Variable ----------------------- `g77' should warn about modifying `DO' variables via `EQUIVALENCE'. (The internal information gathered to produce this warning might also be useful in setting the internal "doiter" flag for a variable or even array reference within a loop, since that might produce faster code someday.) For example, this code is invalid, so `g77' should warn about the invalid assignment to `NOTHER': EQUIVALENCE (I, NOTHER) DO I = 1, 100 IF (I.EQ. 10) NOTHER = 20 END DO File: g77.info, Node: Better Pedantic Compilation, Next: Warn About Implicit Conversions, Prev: Modifying DO Variable, Up: Missing Features Better Pedantic Compilation --------------------------- `g77' needs to support `-fpedantic' more thoroughly, and use it only to generate warnings instead of rejecting constructs outright. Have it warn: if a variable that dimensions an array is not a dummy or placed explicitly in `COMMON' (F77 does not allow it to be placed in `COMMON' via `EQUIVALENCE'); if specification statements follow statement-function-definition statements; about all sorts of syntactic extensions. File: g77.info, Node: Warn About Implicit Conversions, Next: Invalid Use of Hollerith Constant, Prev: Better Pedantic Compilation, Up: Missing Features Warn About Implicit Conversions ------------------------------- `g77' needs a `-Wpromotions' option to warn if source code appears to expect automatic, silent, and somewhat dangerous compiler-assisted conversion of `REAL(KIND=1)' constants to `REAL(KIND=2)' based on context. For example, it would warn about cases like this: DOUBLE PRECISION FOO PARAMETER (TZPHI = 9.435784839284958) FOO = TZPHI * 3D0 File: g77.info, Node: Invalid Use of Hollerith Constant, Next: Dummy Array Without Dimensioning Dummy, Prev: Warn About Implicit Conversions, Up: Missing Features Invalid Use of Hollerith Constant --------------------------------- `g77' should disallow statements like `RETURN 2HAB', which are invalid in both source forms (unlike `RETURN (2HAB)', which probably still makes no sense but at least can be reliably parsed). Fixed-form processing rejects it, but not free-form, except in a way that is a bit difficult to understand. File: g77.info, Node: Dummy Array Without Dimensioning Dummy, Next: Invalid FORMAT Specifiers, Prev: Invalid Use of Hollerith Constant, Up: Missing Features Dummy Array Without Dimensioning Dummy -------------------------------------- `g77' should complain when a list of dummy arguments containing an adjustable dummy array does not also contain every variable listed in the dimension list of the adjustable array. Currently, `g77' does complain about a variable that dimensions an array but doesn't appear in any dummy list or `COMMON' area, but this needs to be extended to catch cases where it doesn't appear in every dummy list that also lists any arrays it dimensions. For example, `g77' should warn about the entry point `ALT' below, since it includes `ARRAY' but not `ISIZE' in its list of arguments: SUBROUTINE PRIMARY(ARRAY, ISIZE) REAL ARRAY(ISIZE) ENTRY ALT(ARRAY) File: g77.info, Node: Invalid FORMAT Specifiers, Next: Ambiguous Dialects, Prev: Dummy Array Without Dimensioning Dummy, Up: Missing Features Invalid FORMAT Specifiers ------------------------- `g77' should check `FORMAT' specifiers for validity as it does `FORMAT' statements. For example, a diagnostic would be produced for: PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!' File: g77.info, Node: Ambiguous Dialects, Next: Unused Labels, Prev: Invalid FORMAT Specifiers, Up: Missing Features Ambiguous Dialects ------------------ `g77' needs a set of options such as `-Wugly*', `-Wautomatic', `-Wvxt', `-Wf90', and so on. These would warn about places in the user's source where ambiguities are found, helpful in resolving ambiguities in the program's dialect or dialects. File: g77.info, Node: Unused Labels, Next: Informational Messages, Prev: Ambiguous Dialects, Up: Missing Features Unused Labels ------------- `g77' should warn about unused labels when `-Wunused' is in effect. File: g77.info, Node: Informational Messages, Next: Uninitialized Variables at Run Time, Prev: Unused Labels, Up: Missing Features Informational Messages ---------------------- `g77' needs an option to suppress information messages (notes). `-w' does this but also suppresses warnings. The default should be to suppress info messages. Perhaps info messages should simply be eliminated. File: g77.info, Node: Uninitialized Variables at Run Time, Next: Bounds Checking at Run Time, Prev: Informational Messages, Up: Missing Features Uninitialized Variables at Run Time ----------------------------------- `g77' needs an option to initialize everything (not otherwise explicitly initialized) to "weird" (machine-dependent) values, e.g. NaNs, bad (non-`NULL') pointers, and largest-magnitude integers, would help track down references to some kinds of uninitialized variables at run time. Note that use of the options `-O -Wuninitialized' can catch many such bugs at compile time. File: g77.info, Node: Bounds Checking at Run Time, Next: Labels Visible to Debugger, Prev: Uninitialized Variables at Run Time, Up: Missing Features Bounds Checking at Run Time --------------------------- `g77' should offer run-time bounds-checking of array/subscript references in a fashion similar to `f2c'. Note that `g77' already warns about references to out-of-bounds elements of arrays when it detects these at compile time. File: g77.info, Node: Labels Visible to Debugger, Prev: Bounds Checking at Run Time, Up: Missing Features Labels Visible to Debugger -------------------------- `g77' should output debugging information for statements labels, for use by debuggers that know how to support them. Same with weirder things like construct names. It is not yet known if any debug formats or debuggers support these. File: g77.info, Node: Disappointments, Next: Non-bugs, Prev: Missing Features, Up: Trouble Disappointments and Misunderstandings ===================================== These problems are perhaps regrettable, but we don't know any practical way around them for now. * Menu: * Mangling of Names:: `SUBROUTINE FOO' is given external name `foo_'. * Multiple Definitions of External Names:: No doing both `COMMON /FOO/' and `SUBROUTINE FOO'. * Limitation on Implicit Declarations:: No `IMPLICIT CHARACTER*(*)'. File: g77.info, Node: Mangling of Names, Next: Multiple Definitions of External Names, Up: Disappointments Mangling of Names in Source Code -------------------------------- The current external-interface design, which includes naming of external procedures, COMMON blocks, and the library interface, has various usability problems, including things like adding underscores where not really necessary (and preventing easier inter-language operability) and yet not providing complete namespace freedom for user C code linked with Fortran apps (due to the naming of functions in the library, among other things). Project GNU should at least get all this "right" for systems it fully controls, such as the Hurd, and provide defaults and options for compatibility with existing systems and interoperability with popular existing compilers. File: g77.info, Node: Multiple Definitions of External Names, Next: Limitation on Implicit Declarations, Prev: Mangling of Names, Up: Disappointments Multiple Definitions of External Names -------------------------------------- `g77' doesn't allow a common block and an external procedure or `BLOCK DATA' to have the same name. Some systems allow this, but `g77' does not, to be compatible with `f2c'. `g77' could special-case the way it handles `BLOCK DATA', since it is not compatible with `f2c' in this particular area (necessarily, since `g77' offers an important feature here), but it is likely that such special-casing would be very annoying to people with programs that use `EXTERNAL FOO', with no other mention of `FOO' in the same program unit, to refer to external procedures, since the result would be that `g77' would treat these references as requests to force-load BLOCK DATA program units. In that case, if `g77' modified names of `BLOCK DATA' so they could have the same names as `COMMON', users would find that their programs wouldn't link because the `FOO' procedure didn't have its name translated the same way. (Strictly speaking, `g77' could emit a null-but-externally-satisfying definition of `FOO' with its name transformed as if it had been a `BLOCK DATA', but that probably invites more trouble than it's worth.) File: g77.info, Node: Limitation on Implicit Declarations, Prev: Multiple Definitions of External Names, Up: Disappointments Limitation on Implicit Declarations ----------------------------------- `g77' disallows `IMPLICIT CHARACTER*(*)'. This is not standard-conforming. File: g77.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Disappointments, Up: Trouble Certain Changes We Don't Want to Make ===================================== This section lists changes that people frequently request, but which we do not make because we think GNU Fortran is better without them. * Menu: * Backslash in Constants:: Why `'\\'' is a constant that is one, not two, characters long. * Initializing Before Specifying:: Why `DATA VAR/1/' can't precede `COMMON VAR'. * Context-Sensitive Intrinsicness:: Why `CALL SQRT' won't work. * Context-Sensitive Constants:: Why `9.435784839284958' is a single-precision constant, and might be interpreted as `9.435785' or similar. * Equivalence Versus Equality:: Why `.TRUE. .EQ. .TRUE.' won't work. * Order of Side Effects:: Why `J = IFUNC() - IFUNC()' might not behave as expected. File: g77.info, Node: Backslash in Constants, Next: Initializing Before Specifying, Up: Non-bugs Backslash in Constants ---------------------- In the opinion of many experienced Fortran users, `-fno-backslash' should be the default, not `-fbackslash', as currently set by `g77'. First of all, you can always specify `-fno-backslash' to turn off this processing. Despite not being within the spirit (though apparently within the letter) of the ANSI FORTRAN 77 standard, `g77' defaults to `-fbackslash' because that is what most UNIX `f77' commands default to, and apparently lots of code depends on this feature. This is a particularly troubling issue. The use of a C construct in the midst of Fortran code is bad enough, worse when it makes existing Fortran programs stop working (as happens when programs written for non-UNIX systems are ported to UNIX systems with compilers that provide the `-fbackslash' feature as the default--sometimes with no option to turn it off). The author of GNU Fortran wished, for reasons of linguistic purity, to make `-fno-backslash' the default for GNU Fortran and thus require users of UNIX `f77' and `f2c' to specify `-fbackslash' to get the UNIX behavior. However, the realization that `g77' is intended as a replacement for *UNIX* `f77', caused the author to choose to make `g77' as compatible with `f77' as feasible, which meant making `-fbackslash' the default. The primary focus on compatibility is at the source-code level, and the question became "What will users expect a replacement for `f77' to do, by default?" Although at least one UNIX `f77' does not provide `-fbackslash' as a default, it appears that the majority of them do, which suggests that the majority of code that is compiled by UNIX `f77' compilers expects `-fbackslash' to be the default. It is probably the case that more code exists that would *not* work with `-fbackslash' in force than code that requires it be in force. However, most of *that* code is not being compiled with `f77', and when it is, new build procedures (shell scripts, makefiles, and so on) must be set up anyway so that they work under UNIX. That makes a much more natural and safe opportunity for non-UNIX users to adapt their build procedures for `g77''s default of `-fbackslash' than would exist for the majority of UNIX `f77' users who would have to modify existing, working build procedures to explicitly specify `-fbackslash' if that was not the default. One suggestion has been to configure the default for `-fbackslash' (and perhaps other options as well) based on the configuration of `g77'. This is technically quite straightforward, but will be avoided even in cases where not configuring defaults to be dependent on a particular configuration greatly inconveniences some users of legacy code. Many users appreciate the GNU compilers because they provide an environment that is uniform across machines. These users would be inconvenienced if the compiler treated things like the format of the source code differently on certain machines. Occasionally users write programs intended only for a particular machine type. On these occasions, the users would benefit if the GNU Fortran compiler were to support by default the same dialect as the other compilers on that machine. But such applications are rare. And users writing a program to run on more than one type of machine cannot possibly benefit from this kind of compatibility. (This is consistent with the design goals for `gcc'. To change them for `g77', you must first change them for `gcc'. Do not ask the maintainers of `g77' to do this for you, or to disassociate `g77' from the widely understood, if not widely agreed-upon, goals for GNU compilers in general.) This is why GNU Fortran does and will treat backslashes in the same fashion on all types of machines (by default). *Note Direction of Language Development::, for more information on this overall philosophy guiding the development of the GNU Fortran language. Of course, users strongly concerned about portability should indicate explicitly in their build procedures which options are expected by their source code, or write source code that has as few such expectations as possible. For example, avoid writing code that depends on backslash (`\') being interpreted either way in particular, such as by starting a program unit with: CHARACTER BACKSL PARAMETER (BACKSL = '\\') Then, use concatenation of `BACKSL' anyplace a backslash is desired. In this way, users can write programs which have the same meaning in many Fortran dialects. (However, this technique does not work for Hollerith constants--which is just as well, since the only generally portable uses for Hollerith constants are in places where character constants can and should be used instead, for readability.) File: g77.info, Node: Initializing Before Specifying, Next: Context-Sensitive Intrinsicness, Prev: Backslash in Constants, Up: Non-bugs Initializing Before Specifying ------------------------------ `g77' does not allow `DATA VAR/1/' to appear in the source code before `COMMON VAR', `DIMENSION VAR(10)', `INTEGER VAR', and so on. In general, `g77' requires initialization of a variable or array to be specified *after* all other specifications of attributes (type, size, placement, and so on) of that variable or array are specified (though *confirmation* of data type is permitted). It is *possible* `g77' will someday allow all of this, even though it is not allowed by the FORTRAN 77 standard. Then again, maybe it is better to have `g77' always require placement of `DATA' so that it can possibly immediately write constants to the output file, thus saving time and space. That is, `DATA A/1000000*1/' should perhaps always be immediately writable to canonical assembler, unless it's already known to be in a `COMMON' area following as-yet-uninitialized stuff, and to do this it cannot be followed by `COMMON A'. File: g77.info, Node: Context-Sensitive Intrinsicness, Next: Context-Sensitive Constants, Prev: Initializing Before Specifying, Up: Non-bugs Context-Sensitive Intrinsicness ------------------------------- `g77' treats procedure references to *possible* intrinsic names as always enabling their intrinsic nature, regardless of whether the *form* of the reference is valid for that intrinsic. For example, `CALL SQRT' is interpreted by `g77' as an invalid reference to the `SQRT' intrinsic function, because the reference is a subroutine invocation. First, `g77' recognizes the statement `CALL SQRT' as a reference to a *procedure* named `SQRT', not to a *variable* with that name (as it would for a statement such as `V = SQRT'). Next, `g77' establishes that, in the program unit being compiled, `SQRT' is an intrinsic--not a subroutine that happens to have the same name as an intrinsic (as would be the case if, for example, `EXTERNAL SQRT' was present). Finally, `g77' recognizes that the *form* of the reference is invalid for that particular intrinsic. That is, it recognizes that it is invalid for an intrinsic *function*, such as `SQRT', to be invoked as a *subroutine*. At that point, `g77' issues a diagnostic. Some users claim that it is "obvious" that `CALL SQRT' references an external subroutine of their own, not an intrinsic function. However, `g77' knows about intrinsic subroutines, not just functions, and is able to support both having the same names, for example. As a result of this, `g77' rejects calls to intrinsics that are not subroutines, and function invocations of intrinsics that are not functions, just as it (and most compilers) rejects invocations of intrinsics with the wrong number (or types) of arguments. So, use the `EXTERNAL SQRT' statement in a program unit that calls a user-written subroutine named `SQRT'. File: g77.info, Node: Context-Sensitive Constants, Next: Equivalence Versus Equality, Prev: Context-Sensitive Intrinsicness, Up: Non-bugs Context-Sensitive Constants --------------------------- `g77' does not use context to determine the types of constants or named constants (`PARAMETER'), except for (non-standard) typeless constants such as `'123'O'. For example, consider the following statement: PRINT *, 9.435784839284958 * 2D0 `g77' will interpret the (truncated) constant `9.435784839284958' as a `REAL(KIND=1)', not `REAL(KIND=2)', constant, because the suffix `D0' is not specified. As a result, the output of the above statement when compiled by `g77' will appear to have "less precision" than when compiled by other compilers. In these and other cases, some compilers detect the fact that a single-precision constant is used in a double-precision context and therefore interpret the single-precision constant as if it was *explicitly* specified as a double-precision constant. (This has the effect of appending *decimal*, not *binary*, zeros to the fractional part of the number--producing different computational results.) The reason this misfeature is dangerous is that a slight, apparently innocuous change to the source code can change the computational results. Consider: REAL ALMOST, CLOSE DOUBLE PRECISION FIVE PARAMETER (ALMOST = 5.000000000001) FIVE = 5 CLOSE = 5.000000000001 PRINT *, 5.000000000001 - FIVE PRINT *, ALMOST - FIVE PRINT *, CLOSE - FIVE END Running the above program should result in the same value being printed three times. With `g77' as the compiler, it does. However, compiled by many other compilers, running the above program would print two or three distinct values, because in two or three of the statements, the constant `5.000000000001', which on most systems is exactly equal to `5.' when interpreted as a single-precision constant, is instead interpreted as a double-precision constant, preserving the represented precision. However, this "clever" promotion of type does not extend to variables or, in some compilers, to named constants. Since programmers often are encouraged to replace manifest constants or permanently-assigned variables with named constants (`PARAMETER' in Fortran), and might need to replace some constants with variables having the same values for pertinent portions of code, it is important that compilers treat code so modified in the same way so that the results of such programs are the same. `g77' helps in this regard by treating constants just the same as variables in terms of determining their types in a context-independent way. Still, there is a lot of existing Fortran code that has been written to depend on the way other compilers freely interpret constants' types based on context, so anything `g77' can do to help flag cases of this in such code could be very helpful. File: g77.info, Node: Equivalence Versus Equality, Next: Order of Side Effects, Prev: Context-Sensitive Constants, Up: Non-bugs Equivalence Versus Equality --------------------------- Use of `.EQ.' and `.NE.' on `LOGICAL' operands is not supported, except via `-fugly', which is not recommended except for legacy code (where the behavior expected by the *code* is assumed). Legacy code should be changed, as resources permit, to use `.EQV.' and `.NEQV.' instead, as these are permitted by the various Fortran standards. New code should never be written expecting `.EQ.' or `.NE.' to work if either of its operands is `LOGICAL'. The problem with supporting this "feature" is that there is unlikely to be consensus on how it works, as illustrated by the following sample program: LOGICAL L,M,N DATA L,M,N /3*.FALSE./ IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N' END The issue raised by the above sample program is: what is the precedence of `.EQ.' (and `.NE.') when applied to `LOGICAL' operands? Some programmers will argue that it is the same as the precedence for `.EQ.' when applied to numeric (such as `INTEGER') operands. By this interpretation, the subexpression `M.EQ.N' must be evaluated first in the above program, resulting in a program that, when run, does not execute the `PRINT' statement. Other programmers will argue that the precedence is the same as the precedence for `.EQV.', which is restricted by the standards to `LOGICAL' operands. By this interpretation, the subexpression `L.AND.M' must be evaluated first, resulting in a program that *does* execute the `PRINT' statement. Assigning arbitrary semantic interpretations to syntactic expressions that might legitimately have more than one "obvious" interpretation is generally unwise. The creators of the various Fortran standards have done a good job in this case, requiring a distinct set of operators (which have their own distinct precedence) to compare `LOGICAL' operands. This requirement results in expression syntax with more certain precedence (without requiring substantial context), making it easier for programmers to read existing code. `g77' will avoid muddying up elements of the Fortran language that were well-designed in the first place. (Ask C programmers about the precedence of expressions such as `(a) & (b)' and `(a) - (b)'--they cannot even tell you, without knowing more context, whether the `&' and `-' operators are infix (binary) or unary!) File: g77.info, Node: Order of Side Effects, Prev: Equivalence Versus Equality, Up: Non-bugs Order of Side Effects --------------------- `g77' does not necessarily produce code that, when run, performs side effects (such as those performed by function invocations) in the same order as in some other compiler--or even in the same order as another version, port, or invocation (using different command-line options) of `g77'. It is never safe to depend on the order of evaluation of side effects. For example, an expression like this may very well behave differently from one compiler to another: J = IFUNC() - IFUNC() There is no guarantee that `IFUNC' will be evaluated in any particular order. Either invocation might happen first. If `IFUNC' returns 5 the first time it is invoked, and returns 12 the second time, `J' might end up with the value `7', or it might end up with `-7'. Generally, in Fortran, procedures with side-effects intended to be visible to the caller are best designed as *subroutines*, not functions. Examples of such side-effects include: * The generation of random numbers that are intended to influence return values. * Performing I/O (other than internal I/O to local variables). * Updating information in common blocks. An example of a side-effect that is not intended to be visible to the caller is a function that maintains a cache of recently calculated results, intended solely to speed repeated invocations of the function with identical arguments. Such a function can be safely used in expressions, because if the compiler optimizes away one or more calls to the function, operation of the program is unaffected (aside from being speeded up). File: g77.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble Warning Messages and Error Messages =================================== The GNU compiler can produce two kinds of diagnostics: errors and warnings. Each kind has a different purpose: *Errors* report problems that make it impossible to compile your program. GNU Fortran reports errors with the source file name, line number, and column within the line where the problem is apparent. *Warnings* report other unusual conditions in your code that *might* indicate a problem, although compilation can (and does) proceed. Warning messages also report the source file name, line number, and column information, but include the text `warning:' to distinguish them from error messages. Warnings might indicate danger points where you should check to make sure that your program really does what you intend; or the use of obsolete features; or the use of nonstandard features of GNU Fortran. Many warnings are issued only if you ask for them, with one of the `-W' options (for instance, `-Wall' requests a variety of useful warnings). *Note:* Currently, the text of the line and a pointer to the column is printed in most `g77' diagnostics. Probably, as of version 0.6, `g77' will no longer print the text of the source line, instead printing the column number following the file name and line number in a form that GNU Emacs recognizes. This change is expected to speed up and reduce the memory usage of the `g77' compiler. *Note Options to Request or Suppress Warnings: Warning Options, for more detail on these and related command-line options. File: g77.info, Node: Open Questions, Next: Bugs, Prev: Trouble, Up: Top Open Questions ************** Please consider offering useful answers to these questions! * How do system administrators and users manage multiple incompatible Fortran compilers on their systems? How can `g77' contribute to this, or at least avoiding intefering with it? Currently, `g77' provides rudimentary ways to choose whether to overwrite portions of other Fortran compilation systems (such as the `f77' command and the `libf2c' library). Is this sufficient? What happens when users choose not to overwrite these--does `g77' work properly in all such installations, picking up its own versions, or does it pick up the existing "alien" versions it didn't overwrite with its own, possibly leading to subtle bugs? * `LOC()' and other intrinsics are probably somewhat misclassified. Is the a need for more precise classification of intrinsics, and if so, what are the appropriate groupings? Is there a need to individually enable/disable/delete/hide intrinsics from the command line? File: g77.info, Node: Bugs, Next: Service, Prev: Open Questions, Up: Top Reporting Bugs ************** Your bug reports play an essential role in making GNU Fortran reliable. When you encounter a problem, the first thing to do is to see if it is already known. *Note Trouble::. If it isn't known, then you should report the problem. Reporting a bug might help you by bringing a solution to your problem, or it might not. (If it does not, look in the service directory; see *Note Service::.) In any case, the principal function of a bug report is to help the entire community by making the next version of GNU Fortran work better. Bug reports are your contribution to the maintenance of GNU Fortran. Since the maintainers are very overloaded, we cannot respond to every bug report. However, if the bug has not been fixed, we are likely to send you a patch and ask you to tell us whether it works. In order for a bug report to serve its purpose, you must include the information that makes for fixing the bug. * Menu: * Criteria: Bug Criteria. Have you really found a bug? * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. * Patches: Sending Patches. How to send a patch for GNU Fortran. *Note Known Causes of Trouble with GNU Fortran: Trouble, for information on problems we already know about. *Note How To Get Help with GNU Fortran: Service, for information on where to ask for help. File: g77.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs Have You Found a Bug? ===================== If you are not sure whether you have found a bug, here are some guidelines: * If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable compilers never crash--they just remain obsolete. * If the compiler produces invalid assembly code, for any input whatever, that is a compiler bug, unless the compiler reports errors (not just warnings) which would ordinarily prevent the assembler from being run. * If the compiler produces valid assembly code that does not correctly execute the input source code, that is a compiler bug. However, you must double-check to make sure, because you might have run into an incompatibility between GNU Fortran and traditional Fortran. These incompatibilities might be considered bugs, but they are inescapable consequences of valuable features. Or you might have a program whose behavior is undefined, which happened by chance to give the desired results with another Fortran compiler. It is best to check the relevant Fortran standard thoroughly if it is possible that the program indeed does something undefined. After you have localized the error to a single source line, it should be easy to check for these things. If your program is correct and well defined, you have found a compiler bug. It might help if, in your submission, you identified the specific language in the relevant Fortran standard that specifies the desired behavior, if it isn't likely to be obvious and agreed-upon by all Fortran users. * If the compiler produces an error message for valid input, that is a compiler bug. * If the compiler does not produce an error message for invalid input, that is a compiler bug. However, you should note that your idea of "invalid input" might be someone else's idea of "an extension" or "support for traditional practice". * If you are an experienced user of Fortran compilers, your suggestions for improvement of GNU Fortran are welcome in any case. Many, perhaps most, bug reports against `g77' turn out to be bugs in the user's code. While we find such bug reports educational, they sometimes take a considerable amount of time to track down or at least respond to--time we could be spending making `g77', not some user's code, better. Some steps you can take to verify that the bug is not certainly in the code you're compiling with `g77': * Compile your code using the `g77' options `-W -Wall -O'. These options enable many useful warning; the `-O' option enables flow analysis that enables the uninitialized-variable warning. If you investigate the warnings and find evidence of possible bugs in your code, fix them first and retry `g77'. * Compile your code using the `g77' options `-finit-local-zero', `-fno-automatic', `-ffloat-store', and various combinations thereof. If your code works with any of these combinations, that is not proof that the bug isn't in `g77'--a `g77' bug exposed by your code might simply be avoided, or have a different, more subtle effect, when different options are used--but it can be a strong indicator that your code is making unawarranted assumptions about the Fortran dialect and/or underlying machine it is being compiled and run on. *Note Overly Convenient Command-Line Options: Overly Convenient Options, for information on the `-fno-automatic' and `-finit-local-zero' options and how to convert their use into selective changes in your own code. * Validate your code with `ftnchek' or a similar code-checking tool. `ftncheck' can be found at `ftp://ftp.netlib.org/fortran' or `ftp://ftp.dsm.fordham.edu'. * Try your code out using other Fortran compilers, such as `f2c'. If it does not work on at least one other compiler (assuming the compiler supports the features the code needs), that is a strong indicator of a bug in the code. However, even if your code works on many compilers *except* `g77', that does *not* mean the bug is in `g77'. It might mean the bug is in your code, and that `g77' simply exposes it more readily than other compilers. File: g77.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs Where to Report Bugs ==================== Send bug reports for GNU Fortran to <fortran@gnu.ai.mit.edu>. Often people think of posting bug reports to a newsgroup instead of mailing them. This sometimes appears to work, but it has one problem which can be crucial: a newsgroup posting does not contain a mail path back to the sender. Thus, if maintainers need more information, they might be unable to reach you. For this reason, you should always send bug reports by mail to the proper mailing list. As a last resort, send bug reports on paper to: GNU Compiler Bugs Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307, USA 
