Go to the first, previous, next, last section, table of contents.

# Known Causes of Trouble with GNU Fortran

This section describes known problems that affect users of GNU Fortran. Most of these are not GNU Fortran bugs per se--if they were, we would fix them. But the result for a user might be like the result of a bug.

Some of these problems are due to bugs in other software, some are missing features that are too much work to add, and some are places where people's opinions differ as to what is best.

Information on bugs that show up when configuring, porting, building, or installing `g77` is not provided here. See section Problems Installing.

(Note that some of this portion of the manual is lifted directly from the `gcc` manual, with minor modifications to tailor it to users of `g77`. Anytime a bug seems to have more to do with the `gcc` portion of `g77`, See section `Known Causes of Trouble with GNU CC' in Using and Porting GNU CC.)

## Bugs Not In GNU Fortran

These are bugs to which the maintainers often have to reply, "but that isn't a bug in `g77`...". Some of these already are fixed in new versions of other software; some still need to be fixed; some are problems with how `g77` is installed or is being used; some just cannot be addressed at this time until more is known about the problem.

Please don't re-report these bugs to the `g77` maintainers--if you must remind someone how important it is to you that the problem be fixed, talk to the people responsible for the other products identified below, but preferably only after you've tried the latest versions of those products. The `g77` maintainers have their hands full working on just fixing and improving `g77`, without serving as a clearinghouse for all bugs that happen to affect `g77` users.

See section Collected Fortran Wisdom, for information on behavior of Fortran programs, and the programs that compile them, that might be thought to indicate bugs.

### Cannot Link Fortran Programs

On some systems, perhaps just those with out-of-date (shared?) libraries, unresolved-reference errors happen when linking `g77`-compiled programs (which should be done using `g77`).

If this happens to you, try appending ``-lc'` to the command you use to link the program, e.g. ``g77 foo.f -lc'`. `g77` already specifies ``-lf2c -lm'` when it calls the linker, but it cannot also specify ``-lc'` because not all systems have a file named ``libc.a'`.

It is unclear at this point whether there are legitimately installed systems where ``-lf2c -lm'` is insufficient to resolve code produced by `g77`.

If your program doesn't link due to unresolved references to names like ``_main'`, make sure you're using the `g77` command to do the link, since this command ensures that the necessary libraries are loaded by specifying ``-lf2c -lm'` when it invokes the `gcc` command to do the actual link. (Use the ``-v'` option to discover more about what actually happens when you use the `g77` and `gcc` commands.)

Also, try specifying ``-lc'` as the last item on the `g77` command line, in case that helps.

### Large Common Blocks

On some older GNU/Linux systems, programs with common blocks larger than 16MB cannot be linked without some kind of error message being produced.

This is a bug in older versions of `ld`, fixed in more recent versions of `binutils`, such as version 2.6.

### Debugger Problems

There are some known problems when using `gdb` on code compiled by `g77`. Inadequate investigation as of the release of 0.5.16 results in not knowing which products are the culprit, but ``gdb-4.14'` definitely crashes when, for example, an attempt is made to print the contents of a `COMPLEX(KIND=2)` dummy array, on at least some GNU/Linux machines, plus some others.

### NeXTStep Problems

Developers of Fortran code on NeXTStep (all architectures) have to watch out for the following problem when writing programs with large, statically allocated (i.e. non-stack based) data structures (common blocks, saved arrays).

Due to the way the native loader (``/bin/ld'`) lays out data structures in virtual memory, it is very easy to create an executable wherein the ``__DATA'` segment overlaps (has addresses in common) with the ``UNIX STACK'` segment.

This leads to all sorts of trouble, from the executable simply not executing, to bus errors. The NeXTStep command line tool `ebadexec` points to the problem as follows:

    % /bin/ebadexec a.out
    /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
    rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
    STACK segment (truncated address = 0x400000 rounded size =
    0x3c00000) of executable file: a.out

(In the above case, it is the ``__LINKEDIT'` segment that overlaps the stack segment.)

This can be cured by assigning the ``__DATA'` segment (virtual) addresses beyond the stack segment. A conservative estimate for this is from address 6000000 (hexadecimal) onwards--this has always worked for me [Toon Moene]:

    % g77 -segaddr __DATA 6000000 test.f
    % ebadexec a.out
    ebadexec: file: a.out appears to be executable
    %

Browsing through ``gcc/f/Makefile.in'`, you will find that the `f771` program itself also has to be linked with these flags--it has large statically allocated data structures. (Version 0.5.18 reduces this somewhat, but probably not enough.)

(The above item was contributed by Toon Moene (@email{toon@moene.indiv.nluug.nl}).)

### Stack Overflow

`g77` code might fail at runtime (probably with a "segmentation violation") due to overflowing the stack. This happens most often on systems with an environment that provides substantially more heap space (for use when arbitrarily allocating and freeing memory) than stack space.

Often this can be cured by increasing or removing your shell's limit on stack usage, typically using `limit stacksize` (in `csh` and derivatives) or `ulimit -s` (in `sh` and derivatives).

Increasing the allowed stack size might, however, require changing some operating system or system configuration parameters.

You might be able to work around the problem by compiling with the ``-fno-automatic'` option to reduce stack usage, probably at the expense of speed.

See section Maximum Stackable Size, for information on patching `g77` to use different criteria for placing local non-automatic variables and arrays on the stack.

However, if your program uses large automatic arrays (for example, has declarations like ``REAL A(N)'` where ``A'` is a local array and ``N'` is a dummy or `COMMON` variable that can have a large value), neither use of ``-fno-automatic'`, nor changing the cut-off point for `g77` for using the stack, will solve the problem by changing the placement of these large arrays, as they are necessarily automatic.

`g77` currently provides no means to specify that automatic arrays are to be allocated on the heap instead of the stack. So, other than increasing the stack size, your best bet is to change your source code to avoid large automatic arrays. Methods for doing this currently are outside the scope of this document.

(Note: If your system puts stack and heap space in the same memory area, such that they are effectively combined, then a stack overflow probably indicates a program that is either simply too large for the system, or buggy.)

### Strange Behavior at Run Time

`g77` code might fail at runtime with "segmentation violation", "bus error", or even something as subtle as a procedure call overwriting a variable or array element that it is not supposed to touch.

These can be symptoms of a wide variety of actual bugs that occurred earlier during the program's run, but manifested themselves as visible problems some time later.

Overflowing the bounds of an array--usually by writing beyond the end of it--is one of two kinds of bug that often occurs in Fortran code.

The other kind of bug is a mismatch between the actual arguments passed to a procedure and the dummy arguments as declared by that procedure.

Both of these kinds of bugs, and some others as well, can be difficult to track down, because the bug can change its behavior, or even appear to not occur, when using a debugger.

That is, these bugs can be quite sensitive to data, including data representing the placement of other data in memory (that is, pointers, such as the placement of stack frames in memory).

Plans call for improving `g77` so that it can offer the ability to catch and report some of these problems at compile, link, or run time, such as by generating code to detect references to beyond the bounds of an array, or checking for agreement between calling and called procedures.

In the meantime, finding and fixing the programming bugs that lead to these behaviors is, ultimately, the user's responsibility, as difficult as that task can sometimes be.

### Floating-point Errors

Some programs appear to produce inconsistent floating-point results compiled by `g77` versus by other compilers.

Often the reason for this behavior is the fact that floating-point values are represented on almost all Fortran systems by approximations, and these approximations are inexact even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8, 0.9, 1.1, and so on. Most Fortran systems, including all current ports of `g77`, use binary arithmetic to represent these approximations.

Therefore, the exact value of any floating-point approximation as manipulated by `g77`-compiled code is representable by adding some combination of the values 1.0, 0.5, 0.25, 0.125, and so on (just keep dividing by two) through the precision of the fraction (typically around 23 bits for `REAL(KIND=1)`, 52 for `REAL(KIND=2)`), then multiplying the sum by a integral power of two (in Fortran, by ``2**N'`) that typically is between -127 and +128 for `REAL(KIND=1)` and -1023 and +1024 for `REAL(KIND=2)`, then multiplying by -1 if the number is negative.

So, a value like 0.2 is exactly represented in decimal--since it is a fraction, ``2/10'`, with a denomenator that is compatible with the base of the number system (base 10). However, ``2/10'` cannot be represented by any finite number of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot be exactly represented in binary notation.

(On the other hand, decimal notation can represent any binary number in a finite number of digits. Decimal notation cannot do so with ternary, or base-3, notation, which would represent floating-point numbers as sums of any of ``1/1'`, ``1/3'`, ``1/9'`, and so on. After all, no finite number of decimal digits can exactly represent ``1/3'`. Fortunately, few systems use ternary notation.)

Moreover, differences in the way run-time I/O libraries convert between these approximations and the decimal representation often used by programmers and the programs they write can result in apparent differences between results that do not actually exist, or exist to such a small degree that they usually are not worth worrying about.

For example, consider the following program:

    PRINT *, 0.2
    END

When compiled by `g77`, the above program might output ``0.20000003'`, while another compiler might produce a executable that outputs ``0.2'`.

This particular difference is due to the fact that, currently, conversion of floating-point values by the `libf2c` library, used by `g77`, handles only double-precision values.

Since ``0.2'` in the program is a single-precision value, it is converted to double precision (still in binary notation) before being converted back to decimal. The conversion to binary appends _binary_ zero digits to the original value--which, again, is an inexact approximation of 0.2--resulting in an approximation that is much less exact than is connoted by the use of double precision.

(The appending of binary zero digits has essentially the same effect as taking a particular decimal approximation of ``1/3'`, such as ``0.3333333'`, and appending decimal zeros to it, producing ``0.33333330000000000'`. Treating the resulting decimal approximation as if it really had 18 or so digits of valid precision would make it seem a very poor approximation of ``1/3'`.)

As a result of converting the single-precision approximation to double precision by appending binary zeros, the conversion of the resulting double-precision value to decimal produces what looks like an incorrect result, when in fact the result is inexact, and is probably no less inaccurate or imprecise an approximation of 0.2 than is produced by other compilers that happen to output the converted value as "exactly" ``0.2'`. (Some compilers behave in a way that can make them appear to retain more accuracy across a conversion of a single-precision constant to double precision. See section Context-Sensitive Constants, to see why this practice is illusory and even dangerous.)

Note that a more exact approximation of the constant is computed when the program is changed to specify a double-precision constant:

    PRINT *, 0.2D0
    END

Future versions of `g77` and/or `libf2c` might convert single-precision values directly to decimal, instead of converting them to double precision first. This would tend to result in output that is more consistent with that produced by some other Fortran implementations.

## Actual Bugs We Haven't Fixed Yet

This section identifies bugs that `g77` users might run into. This includes bugs that are actually in the `gcc` back end (GBE) or in `libf2c`, because those sets of code are at least somewhat under the control of (and necessarily intertwined with) `g77`, so it isn't worth separating them out.

For information on bugs that might afflict people who configure, port, build, and install `g77`, section Problems Installing.

- Work is needed on the `SIGNAL()` intrinsic to ensure that pointers and integers are properly handled on all targets, including 64-bit machines.
- When using ``-fugly-comma'`, `g77` assumes an extra ``%VAL(0)'` argument is to be passed to intrinsics taking no arguments, such as `IARGC()`, which in turn reject such a call. Although this has been worked around for 0.5.18 due to changes in the handling of intrinsics, `g77` needs to do the ugly-argument-appending trick only for external-function invocation, as this would probably be more consistent with compilers that default to using that trick.
- Something about `g77`'s straightforward handling of label references and definitions sometimes prevents the GBE from unrolling loops. Until this is solved, try inserting or removing `CONTINUE` statements as the terminal statement, using the `END DO` form instead, and so on.
- The `g77` command itself should more faithfully process options the way the `gcc` command does. For example, `gcc` accepts abbreviated forms of long options, `g77` generally doesn't.
- Some confusion in diagnostics concerning failing `INCLUDE` statements from within `INCLUDE`'d or `#include`'d files.
- `g77` assumes that `INTEGER(KIND=1)` constants range from ``-2**31'` to ``2**31-1'` (the range for two's-complement 32-bit values), instead of determining their range from the actual range of the type for the configuration (and, someday, for the constant). Further, it generally doesn't implement the handling of constants very well in that it makes assumptions about the configuration that it no longer makes regarding variables (types). Included with this item is the fact that `g77` doesn't recognize that, on IEEE-754/854-compliant systems, ``0./0.'` should produce a NaN and no warning instead of the value ``0.'` and a warning. This is to be fixed in version 0.6, when `g77` will use the `gcc` back end's constant-handling mechanisms to replace its own.
- `g77` uses way too much memory and CPU time to process large aggregate areas having any initialized elements. For example, ``REAL A(1000000)'` followed by ``DATA A(1)/1/'` takes up way too much time and space, including the size of the generated assembler file. This is to be mitigated somewhat in version 0.6. Version 0.5.18 improves cases like this--specifically, cases of sparse initialization that leave large, contiguous areas uninitialized--significantly. However, even with the improvements, these cases still require too much memory and CPU time. (Version 0.5.18 also improves cases where the initial values are zero to a much greater degree, so if the above example ends with ``DATA A(1)/0/'`, the compile-time performance will be about as good as it will ever get, aside from unrelated improvements to the compiler.) Note that `g77` does display a warning message to notify the user before the compiler appears to hang. See section Initialization of Large Aggregate Areas, for information on how to change the point at which `g77` decides to issue this warning.
- `g77` doesn't emit variable and array members of common blocks for use with a debugger (the ``-g'` command-line option). The code is present to do this, but doesn't work with at least one debug format--perhaps it works with others. And it turns out there's a similar bug for local equivalence areas, so that has been disabled as well. As of Version 0.5.19, a temporary kludge solution is provided whereby some rudimentary information on a member is written as a string that is the member's value as a character string. See section Options for Code Generation Conventions, for information on the ``-fdebug-kludge'` option.
- When debugging, after starting up the debugger but before being able to see the source code for the main program unit, the user must currently set a breakpoint at ``MAIN__'` (or ``MAIN___'` or ``MAIN_'` if ``MAIN__'` doesn't exist) and run the program until it hits the breakpoint. At that point, the main program unit is activated and about to execute its first executable statement, but that's the state in which the debugger should start up, as is the case for languages like C.
- Debugging `g77`-compiled code using debuggers other than `gdb` is likely not to work. Getting `g77` and `gdb` to work together is a known problem--getting `g77` to work properly with other debuggers, for which source code often is unavailable to `g77` developers, seems like a much larger, unknown problem, and is a lower priority than making `g77` and `gdb` work together properly. On the other hand, information about problems other debuggers have with `g77` output might make it easier to properly fix `g77`, and perhaps even improve `gdb`, so it is definitely welcome. Such information might even lead to all relevant products working together properly sooner.
- `g77` currently inserts needless padding for things like ``COMMON A,IPAD'` where ``A'` is `CHARACTER*1` and ``IPAD'` is `INTEGER(KIND=1)` on machines like x86, because the back end insists that ``IPAD'` be aligned to a 4-byte boundary, but the processor has no such requirement (though it's good for performance). It is possible that this is not a real bug, and could be considered a performance feature, but it might be important to provide the ability to Fortran code to specify minimum padding for aggregate areas such as common blocks--and, certainly, there is the potential, with the current setup, for interface differences in the way such areas are laid out between `g77` and other compilers.
- Some crashes occur when compiling under Solaris on x86 machines. Nothing has been heard about any such problems for some time, so this is considering a closed item as of 0.5.20. Please submit any bug reports pertinent to `g77`'s support for Solaris/x86 systems.
- RS/6000 support is not complete as of the gcc 2.6.3 back end. The 2.7.0 back end appears to fix this problem, or at least mitigate it significantly, but there is at least one known problem that is likely to be a code-generation bug in ``gcc-2.7.0'` plus ``g77-0.5.16'`. This problem shows up only when compiling the Fortran program with ``-O'`. Nothing has been heard about any RS/6000 problems for some time, so this is considering a closed item as of 0.5.20. Please submit any bug reports pertinent to `g77`'s support for RS/6000 systems.
- SGI support is known to be a bit buggy. The known problem shows up only when compiling the Fortran program with ``-O'`. It is possible these problems have all been fixed in 0.5.20 by emulating complex arithmetic in the front end. Please submit any bug reports pertinent to `g77`'s support for SGI systems.
- `g77` doesn't work perfectly on 64-bit configurations such as the Alpha. This problem is expected to be largely resolved as of version 0.5.20, and version 0.6 should solve most or all related problems (such as 64-bit machines other than DEC Alphas). One known bug that causes a compile-time crash occurs when compiling code such as the following with optimization:

      SUBROUTINE CRASH (TEMP)
      INTEGER*2 HALF(2)
      REAL TEMP
      HALF(1) = NINT (TEMP)
      END

  It is expected that a future version of `g77` will have a fix for this problem, almost certainly by the time `g77` supports the forthcoming version 2.8.0 of `gcc`.
- Maintainers of gcc report that the back end definitely has "broken" support for `COMPLEX` types. Based on their input, it seems many of the problems affect only the more-general facilities for gcc's `__complex__` type, such as `__complex__ int` (where the real and imaginary parts are integers) that GNU Fortran does not use. Version 0.5.20 of `g77` works around this problem by not using the back end's support for `COMPLEX`. The new option ``-fno-emulate-complex'` avoids the work-around, reverting to using the same "broken" mechanism as that used by versions of `g77` prior to 0.5.20.
- There seem to be some problems with passing constants, and perhaps general expressions (other than simple variables/arrays), to procedures when compiling on some systems (such as i386) with ``-fPIC'`, as in when compiling for ELF targets. The symptom is that the assembler complains about invalid opcodes. More investigation is needed, but the problem is almost certainly in the gcc back end, and it apparently occurs only when compiling sufficiently complicated functions without the ``-O'` option.

## Missing Features

This section lists features we know are missing from `g77`, and which we want to add someday. (There is no priority implied in the ordering below.)

### Better Source Model

`g77` needs to provide, as the default source-line model, a "pure visual" mode, where the interpretation of a source program in this mode can be accurately determined by a user looking at a traditionally displayed rendition of the program (assuming the user knows whether the program is fixed or free form).

The design should assume the user cannot tell tabs from spaces and cannot see trailing spaces on lines, but has canonical tab stops and, for fixed-form source, has the ability to always know exactly where column 72 is (since the Fortran standard itself requires this for fixed-form source).

This would change the default treatment of fixed-form source to not treat lines with tabs as if they were infinitely long--instead, they would end at column 72 just as if the tabs were replaced by spaces in the canonical way.

As part of this, provide common alternate models (Digital, `f2c`, and so on) via command-line options. This includes allowing arbitrarily long lines for free-form source as well as fixed-form source and providing various limits and diagnostics as appropriate.

Also, `g77` should offer, perhaps even default to, warnings when characters beyond the last valid column are anything other than spaces. This would mean code with "sequence numbers" in columns 73 through 80 would be rejected, and there's a lot of that kind of code around, but one of the most frequent bugs encountered by new users is accidentally writing fixed-form source code into and beyond column 73. So, maybe the users of old code would be able to more easily handle having to specify, say, a `-Wno-col73to80` option.

### Fortran 90 Support

`g77` does not support many of the features that distinguish Fortran 90 (and, now, Fortran 95) from ANSI FORTRAN 77.

Some Fortran 90 features are supported, because they make sense to offer even to die-hard users of F77. For example, many of them codify various ways F77 has been extended to meet users' needs during its tenure, so `g77` might as well offer them as the primary way to meet those same needs, even if it offers compatibility with one or more of the ways those needs were met by other F77 compilers in the industry.

Still, many important F90 features are not supported, because no attempt has been made to research each and every feature and assess its viability in `g77`. In the meantime, users who need those features must use Fortran 90 compilers anyway, and the best approach to adding some F90 features to GNU Fortran might well be to fund a comprehensive project to create GNU Fortran 95.

### Intrinsics in `PARAMETER` Statements

`g77` doesn't allow intrinsics in `PARAMETER` statements. This feature is considered to be absolutely vital, even though it is not standard-conforming, and is scheduled for version 0.6.

Related to this, `g77` doesn't allow non-integral exponentiation in `PARAMETER` statements, such as ``PARAMETER (R=2**.25)'`. It is unlikely `g77` will ever support this feature, as doing it properly requires complete emulation of a target computer's floating-point facilities when building `g77` as a cross-compiler. But, if the `gcc` back end is enhanced to provide such a facility, `g77` will likely use that facility in implementing this feature soon afterwards.

### `SELECT CASE` on `CHARACTER` Type

Character-type selector/cases for `SELECT CASE` currently are not supported.

### `RECURSIVE` Keyword

`g77` doesn't support the `RECURSIVE` keyword that F90 compilers do. Nor does it provide any means for compiling procedures designed to do recursion.

All recursive code can be rewritten to not use recursion, but the result is not pretty.

### Increasing Precision/Range

Some compilers, such as `f2c`, have an option (``-r8'` or similar) that provides automatic treatment of `REAL` entities such that they have twice the storage size, and a corresponding increase in the range and precision, of what would normally be the `REAL(KIND=1)` (default `REAL`) type. (This affects `COMPLEX` the same way.)

They also typically offer another option (``-i8'`) to increase `INTEGER` entities so they are twice as large (with roughly twice as much range).

(There are potential pitfalls in using these options.)

`g77` does not yet offer any option that performs these kinds of transformations. Part of the problem is the lack of detailed specifications regarding exactly how these options affect the interpretation of constants, intrinsics, and so on.

Until `g77` addresses this need, programmers could improve the portability of their code by modifying it to not require compile-time options to produce correct results. Some free tools are available which may help, specifically in Toolpack (which one would expect to be sound) and the ``fortran'` section of the Netlib repository.

Use of preprocessors can provide a fairly portable means to work around the lack of widely portable methods in the Fortran language itself (though increasing acceptance of Fortran 90 would alleviate this problem).

### Popular Non-standard Types

`g77` doesn't fully support `INTEGER*2`, `LOGICAL*1`, and similar. Version 0.6 will provide full support for this very popular set of features. In the meantime, version 0.5.18 provides rudimentary support for them.

### Full Support for Compiler Types

`g77` doesn't support `INTEGER`, `REAL`, and `COMPLEX` equivalents for all applicable back-end-supported types (`char`, `short int`, `int`, `long int`, `long long int`, and `long double`). This means providing intrinsic support, and maybe constant support (using F90 syntax) as well, and, for most machines will result in automatic support of `INTEGER*1`, `INTEGER*2`, `INTEGER*8`, maybe even `REAL*16`, and so on. This is scheduled for version 0.6.

### Array Bounds Expressions

`g77` doesn't support more general expressions to dimension arrays, such as array element references, function references, etc.

For example, `g77` currently does not accept the following:

    SUBROUTINE X(M, N)
    INTEGER N(10), M(N(2), N(1))

### POINTER Statements

`g77` doesn't support pointers or allocatable objects (other than automatic arrays). This set of features is probably considered just behind intrinsics in `PARAMETER` statements on the list of large, important things to add to `g77`.

### Sensible Non-standard Constructs

`g77` rejects things other compilers accept, like ``INTRINSIC SQRT,SQRT'`. As time permits in the future, some of these things that are easy for humans to read and write and unlikely to be intended to mean something else will be accepted by `g77` (though ``-fpedantic'` should trigger warnings about such non-standard constructs).

Until `g77` no longer gratuitously rejects sensible code, you might as well fix your code to be more standard-conforming and portable.

The kind of case that is important to except from the recommendation to change your code is one where following good coding rules would force you to write non-standard code that nevertheless has a clear meaning.

For example, when writing an `INCLUDE` file that defines a common block, it might be appropriate to include a `SAVE` statement for the common block (such as ``SAVE /CBLOCK/'`), so that variables defined in the common block retain their values even when all procedures declaring the common block become inactive (return to their callers).

However, putting `SAVE` statements in an `INCLUDE` file would prevent otherwise standard-conforming code from also specifying the `SAVE` statement, by itself, to indicate that all local variables and arrays are to have the `SAVE` attribute.

For this reason, `g77` already has been changed to allow this combination, because although the general problem of gratuitously rejecting unambiguous and "safe" constructs still exists in `g77`, this particular construct was deemed useful enough that it was worth fixing `g77` for just this case.

So, while there is no need to change your code to avoid using this particular construct, there might be other, equally appropriate but non-standard constructs, that you shouldn't have to stop using just because `g77` (or any other compiler) gratuitously rejects it.

Until the general problem is solved, if you have any such construct you believe is worthwhile using (e.g. not just an arbitrary, redundant specification of an attribute), please submit a bug report with an explanation, so we can consider fixing `g77` just for cases like yours.

### `FLUSH` Statement

`g77` could perhaps use a `FLUSH` statement that does what ``CALL FLUSH'` does, but that supports ``*'` as the unit designator (same unit as for `PRINT`) and accepts `ERR=` and/or `IOSTAT=` specifiers.

### Expressions in `FORMAT` Statements

`g77` doesn't support ``FORMAT(I<J>)'` and the like. Supporting this requires a significant redesign or replacement of `libf2c`.

However, a future version of `g77` might support this construct when the expression is constant. For example:

          PARAMETER (IWIDTH = 12)
    10    FORMAT (I<IWIDTH>)

In the meantime, at least for output (`PRINT` and `WRITE`), Fortran code making use of this feature can be rewritten to avoid it by constructing the `FORMAT` string in a `CHARACTER` variable or array, then using that variable or array in place of the `FORMAT` statement label to do the original `PRINT` or `WRITE`.

Many uses of this feature on input can be rewritten this way as well, but not all can. For example, this can be rewritten:

          READ 20, I
    20    FORMAT (I<J>)

However, this cannot, in general, be rewritten, especially when `ERR=` and `END=` constructs are employed:

          READ 30, J, I
    30    FORMAT (I<J>)

### Explicit Assembler Code

`g77` needs to provide some way, a la `gcc`, for `g77` code to specify explicit assembler code.

### Old-style PARAMETER Statements

`g77` doesn't accept ``PARAMETER I=1'`. Supporting this obsolete form of the `PARAMETER` statement would not be particularly hard, as most of the parsing code is already in place and working.

Until time/money is spent implementing it, you might as well fix your code to use the standard form, ``PARAMETER (I=1)'` (possibly needing ``INTEGER I'` preceding the `PARAMETER` statement as well, otherwise, in the obsolete form of `PARAMETER`, the type of the variable is set from the type of the constant being assigned to it).

### `TYPE` and `ACCEPT` I/O Statements

`g77` doesn't support the I/O statements `TYPE` and `ACCEPT`. These are common extensions that should be easy to support, but also are fairly easy to work around in user code.

Generally, any ``TYPE fmt,list'` I/O statement can be replaced by ``PRINT fmt,list'`. And, any ``ACCEPT fmt,list'` statement can be replaced by ``READ fmt,list'`.

### `STRUCTURE`, `UNION`, `RECORD`, `MAP`

`g77` doesn't support `STRUCTURE`, `UNION`, `RECORD`, `MAP`. This set of extensions is quite a bit lower on the list of large, important things to add to `g77`, partly because it requires a great deal of work either upgrading or replacing `libf2c`.

### `OPEN`, `CLOSE`, and `INQUIRE` Keywords

`g77` doesn't have support for keywords such as `DISP='DELETE'` in the `OPEN`, `CLOSE`, and `INQUIRE` statements. These extensions are easy to add to `g77` itself, but require much more work on `libf2c`.

### `ENCODE` and `DECODE`

`g77` doesn't support `ENCODE` or `DECODE`.

These statements are best replaced by READ and WRITE statements involving internal files (CHARACTER variables and arrays).

For example, replace a code fragment like

          INTEGER*1 LINE(80)
    ...
          DECODE (80, 9000, LINE) A, B, C
    ...
    9000  FORMAT (1X, 3(F10.5))

with:

          CHARACTER*80 LINE
    ...
          READ (UNIT=LINE, FMT=9000) A, B, C
    ...
    9000  FORMAT (1X, 3(F10.5))

Similarly, replace a code fragment like

          INTEGER*1 LINE(80)
    ...
          ENCODE (80, 9000, LINE) A, B, C
    ...
    9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))

with:

          CHARACTER*80 LINE
    ...
          WRITE (UNIT=LINE, FMT=9000) A, B, C
    ...
    9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))

It is entirely possible that `ENCODE` and `DECODE` will be supported by a future version of `g77`.

### Suppressing Space Padding of Source Lines

`g77` should offer VXT-Fortran-style suppression of virtual spaces at the end of a source line if an appropriate command-line option is specified.

This affects cases where a character constant is continued onto the next line in a fixed-form source file, as in the following example:

    10    PRINT *,'HOW MANY
         1 SPACES?'

`g77`, and many other compilers, virtually extend the continued line through column 72 with spaces that become part of the character constant, but Digital Fortran normally didn't, leaving only one space between ``MANY'` and ``SPACES?'` in the output of the above statement.

Fairly recently, at least one version of Digital Fortran was enhanced to provide the other behavior when a command-line option is specified, apparently due to demand from readers of the USENET group ``comp.lang.fortran'` to offer conformance to this widespread practice in the industry. `g77` should return the favor by offering conformance to Digital's approach to handling the above example.

### Fortran Preprocessor

`g77` should offer a preprocessor designed specifically for Fortran to replace ``cpp -traditional'`. There are several out there worth evaluating, at least.

Such a preprocessor would recognize Hollerith constants, properly parse comments and character constants, and so on.

### Bit Operations on Floating-point Data

`g77` does not allow `REAL` and other non-integral types for arguments to intrinsics like `AND`, `OR`, and `SHIFT`.

For example, this program is rejected by `g77`, because the intrinsic `IAND` does not accept `REAL` arguments:

    DATA A/7.54/, B/9.112/
    PRINT *, IAND(A, B)
    END

### `POSIX` Standard

`g77` should support the POSIX standard for Fortran.

### 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));
    }

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

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

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

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

### Non-standard Conversions

``-Wconversion'` and related should flag places where non-standard conversions are found. Perhaps much of this would be part of ``-Wugly*'`.

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

### 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

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

### 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

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

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

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

### Unused Labels

`g77` should warn about unused labels when ``-Wunused'` is in effect.

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

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

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

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

## Disappointments and Misunderstandings

These problems are perhaps regrettable, but we don't know any practical way around them for now.

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

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

### Limitation on Implicit Declarations

`g77` disallows `IMPLICIT CHARACTER*(*)`. This is not standard-conforming.

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

### 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). See section 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.)

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

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

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

### 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!)

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

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

See section Options to Request or Suppress Warnings, for more detail on these and related command-line options.

Go to the first, previous, next, last section, table of contents.