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,
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.)
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.
ld, fixed in
more recent versions of binutils, such as version 2.6.
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*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'.
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.
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, because some systems need it and g77 doesn't do it
automatically.
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
(toon@moene.indiv.nluug.nl).)
g77 rejects 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.
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.
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.
g77 generally 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.
g77 needs 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.
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.
g77 could use a `--help' option of some sort.
g77 assumes 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 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.
g77 currently 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 g77 and other
compilers.
g77 doesn'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 gcc they
are using.
g77 uses 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.
gcc.
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.)
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 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 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 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.
g77 does not allow `REAL' and other non-integral types for
arguments to intrinsics like `AND', `OR', and `SHIFT'.
g77 doesn'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.
g77 rejects 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, 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.
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).
g77 doesn'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 g77.
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.
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.
g77 itself, but
require much more work on libf2c.
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.
g77 doesn't support `FORMAT(I<J>)' and the like.
Supporting this requires a significant redesign or replacement
of libf2c.
gcc, for g77 code 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.
f2c.
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.
g77 should 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',
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.)
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.
libU77 should be
provided in addition to the few utility routines in libf2c.
Much of this work has already been done, and is awaiting
integration into g77.
These problems are perhaps regrettable, but we don't know any practical way around them for now.
g77 disallows `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.
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.)
This section lists changes that people frequently request, but which we do not make because we think GNU Fortran is better without them.
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, by far,
the majority of them do, which suggests that, by far,
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.
g77 does not use context to determine the types of
constants or named constants (`PARAMETER').
For example, consider the following statement:
PRINT *, 3.1415926535 * 2D0
g77 will 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 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 ENDRunning 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.
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 IFIX' is interpreted by g77 first 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 g77
recognize that the form of the reference is invalid for that
particular intrinsic.
At that point, g77 issues a diagnostic.
Some users claim that it is "obvious" that `CALL IFIX'
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.
Use the `EXTERNAL IFIX' statement in a program unit that calls
a user-written subroutine named `IFIX'.
g77 will someday allow this.
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'.
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 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.