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.

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.

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

Disappointments and Misunderstandings

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

Limitation on Implicit Declarations

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

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

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.

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

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. (However, this technique does not work for Hollerith constants--which is good, since the only generally portable uses for Hollerith constants are in places where character constants can and should be used instead, for readability.)

In this way, users can write programs which have the same meaning in many Fortran dialects.

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', not `DOUBLE PRECISION', 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!)

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

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

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:

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:

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.