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 may 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,
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
Anytime a bug seems to have more to do with the
See section `Known Causes of Trouble with GNU CC' in Using and Porting GNU CC.)
These are bugs to which the maintainers often have to reply,
"but that isn't a bug in
Some of these already are fixed in new versions of other
software; some still need to be fixed; some are problems
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
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.
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
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.
ld, fixed in more recent versions of
binutils, such as version 2.6.
gdbon 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*16' dummy array, on at least some Linux machines, plus some others.
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'.
g77already 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
g77command to do the link, since this command ensures that the necessary libraries are loaded by specifying `-lf2c -lm' when it invokes the
gcccommand to do the actual link. (Use the `-v' option to discover more about what actually happens when you use the
gcccommands.) Also, try specifying `-lc' as the last item on the
g77command line, because some systems need it and
g77doesn't do it automatically.
ebadexecpoints 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
f771program 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 (
g77rejects 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
g77when the `-fugly' option is specified.
This section identifies bugs that
might run into.
This includes bugs that are actually in the
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
section Problems Installing.
g77assumes 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,
g77needs 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.
g77generally supports `SELECT CASE', it doesn't do so for `CHARACTER' types. Worse, it just crashes with a barely servicable diagnostic. If the time can't be taken soon to finish implementing this feature, at least a better way of diagnosing the problem should be provided.
g77needs to accept `FORMAT' and `ENTRY' before an `IMPLICIT NONE'.
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.
g77command itself should more faithfully process options the way the
gcccommand does. For example,
gccaccepts abbreviated forms of long options,
g77could use a `--help' option of some sort.
g77assumes that `INTEGER' 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 `INTEGER' 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
g77doesn'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
g77will use the
gccback end's constant-handling mechanisms to replace its own.
g77uses 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
g77does 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
g77decides to issue this warning.
g77doesn'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.
g77currently inserts needless padding for things like `COMMON A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER*4' 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
g77and other compilers.
g77doesn't work on 64-bit configurations such as the Alpha. The problem is not yet adequately investigated, and some Alpha users are having quite a bit of success, so perhaps it depends on the OS and configuration of
gccthey are using.
g77uses to implement `COMPLEX' and `DOUBLE COMPLEX'. More investigation is needed, but bug reports are definitely welcome, since that can help speed investigation of problem areas.
This section lists features we know are missing from
and which we want to add someday.
(There is no priority implied in the ordering below.)
g77does not support many of the features that distinguish Fortran 90 (and, now, Fortran 95) from ANSI FORTRAN 77. Some Fortran 90 features are listed here, 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
g77might 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 listed here, 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.
g77does not allow `REAL' and other non-integral types for arguments to intrinsics like `AND', `OR', and `SHIFT'.
g77doesn't support `INTEGER*2', `LOGICAL*1', and similar. Version 0.6 will provide full support for this extremely important set of features. In the meantime, version 0.5.18 provides rudimentary support for them.
g77rejects things other compilers accept, like `INTRINSIC SIN,SIN'. 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). In the meantime, 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,
g77already 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
g77for 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
g77just for cases like yours.
g77doesn'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).
g77doesn't support pointers or allocatable objects. This set of features is probably considered just behind `INTEGER*2' and intrinsics in `PARAMETER' statements on the list of large, important things to add to
g77doesn'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.
g77doesn'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
g77itself, but require much more work on
g77doesn'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,
g77doesn't allow non-integral exponentiation in `PARAMETER' statements, such as `PARAMETER (R=2**.25)'. It is unlikely
g77will ever support this feature, as doing it properly requires complete emulation of a target computer's floating-point facilities when building
g77as a cross-compiler. But, if the
gccback end is enhanced to provide such a facility,
g77will likely use that facility in implementing this feature soon afterwards.
g77doesn't support `FORMAT(I<J>)' and the like. Supporting this requires a significant redesign or replacement of
g77code to specify assembler code.
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.
10 PRINT *,'HOW MANY 1 SPACES?'
g77, and many other compilers, virtually extend the continued line through column 72 with blanks 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.
g77should return the favor by offering conformance to Digital's approach to handling the above example.
DOUBLE PRECISION FOO PARAMETER (PI = 3.14159) FOO = PI * 3D0
INTRINSIC ZABS CALL FOO(ZABS) ENDWhen compiling the above with `-ff2c-intrinsics-disable',
g77should 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.)
g77does 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.
libU77should be provided in addition to the few utility routines in
libf2c. Much of this work has already been done, and is awaiting integration into
These problems are perhaps regrettable, but we don't know any practical way around them for now.
g77disallows `IMPLICIT CHARACTER*(*)'. This is not standard-conforming, and there are some very good reasons for that. When I next remember any, I'll try to write them down.
g77doesn't allow a common block and an external procedure or `BLOCK DATA' to have the same name. Some systems allow this, but
g77does not, to be compatible with
g77could special-case the way it handles `BLOCK DATA', since it is not compatible with
f2cin this particular area (necessarily, since
g77offers 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
g77would treat these references as requests to force-load BLOCK DATA program units. In that case, if
g77modified 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,
g77could 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.)
This section lists changes that people frequently request, but which we do not make because we think GNU Fortran is better without them.
g77defaults to `-fbackslash' because that is what most UNIX
f77commands 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
f2cto specify `-fbackslash' to get the UNIX behavior. However, the realization that
g77is intended as a replacement for UNIX
f77, caused the author to choose to make
g77as compatible with
f77as 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
f77to do, by default?" Although at least one UNIX
f77does not provide `-fbackslash' as a default, it appears that, by far, the majority of them do, which suggests that, by far, the majority of code that is compiled by UNIX
f77compilers 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
f77users 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
g77to do this for you, or to disassociate
g77from 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.
g77does not use context to determine the types of constants or named constants (`PARAMETER'). For example, consider the following statement:
PRINT *, 3.1415926535 * 2D0
g77will interpret the (truncated) constant `3.1415926535' 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
g77will 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 ENDRunning the above program should result in the same value being printed three times. With
g77as 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.
g77helps 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
g77can do to help flag cases of this in such code could be very helpful.
g77treats 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 IFIX' is interpreted by
g77first as a reference to the `IFIX' intrinsic, because the reference is a procedure invocation (as compared to `J=IFIX'); only after establishing that, in the program unit being compiled, `IFIX' is in fact an intrinsic and not a local name that happens to have the same name as an intrinsic, does
g77recognize that the form of the reference is invalid for that particular intrinsic. At that point,
g77issues a diagnostic. Some users claim that it is "obvious" that `CALL IFIX' references an external subroutine of their own, not an intrinsic function. However,
g77knows about intrinsic subroutines, not just functions, and is able to support both having the same names, for example. As a result of this,
g77rejects 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. Use the `EXTERNAL IFIX' statement in a program unit that calls a user-written subroutine named `IFIX'.
g77will someday allow this. Then again, maybe it is better to have
g77always 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'.
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 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
Probably, as of version 0.6,
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
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.