261 lines
9.5 KiB
Plaintext
261 lines
9.5 KiB
Plaintext
@c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2004 Free Software Foundation, Inc.
|
|
@c This is part of the G77 manual.
|
|
@c For copying conditions, see the file g77.texi.
|
|
|
|
@c The text of this file appears in the file BUGS
|
|
@c in the G77 distribution, as well as in the G77 manual.
|
|
|
|
@c Keep this the same as the dates above, since it's used
|
|
@c in the standalone derivations of this file (e.g. BUGS).
|
|
@set copyrights-bugs 1995,1996,1997,1998,1999,2000,2001,2002,2004
|
|
|
|
@set last-update-bugs 2004-05-18
|
|
|
|
@ifset DOC-BUGS
|
|
@include root.texi
|
|
@c The immediately following lines apply to the BUGS file
|
|
@c which is derived from this file.
|
|
@emph{Note:} This file is automatically generated from the files
|
|
@file{bugs0.texi} and @file{bugs.texi}.
|
|
@file{BUGS} is @emph{not} a source file,
|
|
although it is normally included within source distributions.
|
|
|
|
This file lists known bugs in the @value{which-g77} version
|
|
of the GNU Fortran compiler.
|
|
Copyright (C) @value{copyrights-bugs} Free Software Foundation, Inc.
|
|
You may copy, distribute, and modify it freely as long as you preserve
|
|
this copyright notice and permission notice.
|
|
|
|
@node Top,,, (dir)
|
|
@chapter Known Bugs In GNU Fortran
|
|
@end ifset
|
|
|
|
@ifset DOC-G77
|
|
@node Known Bugs
|
|
@section Known Bugs In GNU Fortran
|
|
@end ifset
|
|
|
|
This section identifies bugs that @code{g77} @emph{users}
|
|
might run into in the @value{which-g77} version
|
|
of @code{g77}.
|
|
This includes bugs that are actually in the @code{gcc}
|
|
back end (GBE) or in @code{libf2c}, because those
|
|
sets of code are at least somewhat under the control
|
|
of (and necessarily intertwined with) @code{g77},
|
|
so it isn't worth separating them out.
|
|
|
|
@ifset DOC-G77
|
|
For information on bugs in @emph{other} versions of @code{g77},
|
|
see @ref{News,,News About GNU Fortran}.
|
|
There, lists of bugs fixed in various versions of @code{g77}
|
|
can help determine what bugs existed in prior versions.
|
|
@end ifset
|
|
|
|
@ifset DOC-BUGS
|
|
For information on bugs in @emph{other} versions of @code{g77},
|
|
see @file{@value{path-g77}/NEWS}.
|
|
There, lists of bugs fixed in various versions of @code{g77}
|
|
can help determine what bugs existed in prior versions.
|
|
@end ifset
|
|
|
|
@ifset DEVELOPMENT
|
|
@emph{Warning:} The information below is still under development,
|
|
and might not accurately reflect the @code{g77} code base
|
|
of which it is a part.
|
|
Efforts are made to keep it somewhat up-to-date,
|
|
but they are particularly concentrated
|
|
on any version of this information
|
|
that is distributed as part of a @emph{released} @code{g77}.
|
|
|
|
In particular, while this information is intended to apply to
|
|
the @value{which-g77} version of @code{g77},
|
|
only an official @emph{release} of that version
|
|
is expected to contain documentation that is
|
|
most consistent with the @code{g77} product in that version.
|
|
@end ifset
|
|
|
|
The following information was last updated on @value{last-update-bugs}:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@code{g77} fails to warn about
|
|
use of a ``live'' iterative-DO variable
|
|
as an implied-DO variable
|
|
in a @code{WRITE} or @code{PRINT} statement
|
|
(although it does warn about this in a @code{READ} statement).
|
|
|
|
@item
|
|
Something about @code{g77}'s straightforward handling of
|
|
label references and definitions sometimes prevents the GBE
|
|
from unrolling loops.
|
|
Until this is solved, try inserting or removing @code{CONTINUE}
|
|
statements as the terminal statement, using the @code{END DO}
|
|
form instead, and so on.
|
|
|
|
@item
|
|
Some confusion in diagnostics concerning failing @code{INCLUDE}
|
|
statements from within @code{INCLUDE}'d or @code{#include}'d files.
|
|
|
|
@cindex integer constants
|
|
@cindex constants, integer
|
|
@item
|
|
@code{g77} assumes that @code{INTEGER(KIND=1)} constants range
|
|
from @samp{-2**31} to @samp{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 @code{g77} doesn't recognize
|
|
that, on IEEE-754/854-compliant systems, @samp{0./0.} should produce a NaN
|
|
and no warning instead of the value @samp{0.} and a warning.
|
|
|
|
@cindex compiler speed
|
|
@cindex speed, of compiler
|
|
@cindex compiler memory usage
|
|
@cindex memory usage, of compiler
|
|
@cindex large aggregate areas
|
|
@cindex initialization, bug
|
|
@cindex DATA statement
|
|
@cindex statements, DATA
|
|
@item
|
|
@code{g77} uses way too much memory and CPU time to process large aggregate
|
|
areas having any initialized elements.
|
|
|
|
For example, @samp{REAL A(1000000)} followed by @samp{DATA A(1)/1/}
|
|
takes up way too much time and space, including
|
|
the size of the generated assembler file.
|
|
|
|
Version 0.5.18 improves cases like this---specifically,
|
|
cases of @emph{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 @samp{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 @code{g77} does display a warning message to
|
|
notify the user before the compiler appears to hang.
|
|
@ifset DOC-G77
|
|
A warning message is issued when @code{g77} sees code that provides
|
|
initial values (e.g. via @code{DATA}) to an aggregate area (@code{COMMON}
|
|
or @code{EQUIVALENCE}, or even a large enough array or @code{CHARACTER}
|
|
variable)
|
|
that is large enough to increase @code{g77}'s compile time by roughly
|
|
a factor of 10.
|
|
|
|
This size currently is quite small, since @code{g77}
|
|
currently has a known bug requiring too much memory
|
|
and time to handle such cases.
|
|
In @file{@value{path-g77}/data.c}, the macro
|
|
@code{FFEDATA_sizeTOO_BIG_INIT_} is defined
|
|
to the minimum size for the warning to appear.
|
|
The size is specified in storage units,
|
|
which can be bytes, words, or whatever, on a case-by-case basis.
|
|
|
|
After changing this macro definition, you must
|
|
(of course) rebuild and reinstall @code{g77} for
|
|
the change to take effect.
|
|
|
|
Note that, as of version 0.5.18, improvements have
|
|
reduced the scope of the problem for @emph{sparse}
|
|
initialization of large arrays, especially those
|
|
with large, contiguous uninitialized areas.
|
|
However, the warning is issued at a point prior to
|
|
when @code{g77} knows whether the initialization is sparse,
|
|
and delaying the warning could mean it is produced
|
|
too late to be helpful.
|
|
|
|
Therefore, the macro definition should not be adjusted to
|
|
reflect sparse cases.
|
|
Instead, adjust it to generate the warning when densely
|
|
initialized arrays begin to cause responses noticeably slower
|
|
than linear performance would suggest.
|
|
@end ifset
|
|
|
|
@cindex code, displaying main source
|
|
@cindex displaying main source code
|
|
@cindex debugging main source code
|
|
@cindex printing main source
|
|
@item
|
|
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 @code{MAIN__} (or @code{MAIN___} or @code{MAIN_} if
|
|
@code{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.
|
|
|
|
@cindex debugger
|
|
@item
|
|
Debugging @code{g77}-compiled code using debuggers other than
|
|
@code{gdb} is likely not to work.
|
|
|
|
Getting @code{g77} and @code{gdb} to work together is a known
|
|
problem---getting @code{g77} to work properly with other
|
|
debuggers, for which source code often is unavailable to @code{g77}
|
|
developers, seems like a much larger, unknown problem,
|
|
and is a lower priority than making @code{g77} and @code{gdb}
|
|
work together properly.
|
|
|
|
On the other hand, information about problems other debuggers
|
|
have with @code{g77} output might make it easier to properly
|
|
fix @code{g77}, and perhaps even improve @code{gdb}, so it
|
|
is definitely welcome.
|
|
Such information might even lead to all relevant products
|
|
working together properly sooner.
|
|
|
|
@cindex Alpha, support
|
|
@cindex support, Alpha
|
|
@item
|
|
@code{g77} doesn't work perfectly on 64-bit configurations
|
|
such as the Digital Semiconductor (``DEC'') Alpha.
|
|
|
|
This problem is largely resolved as of version 0.5.23.
|
|
|
|
@cindex padding
|
|
@cindex structures
|
|
@cindex common blocks
|
|
@cindex equivalence areas
|
|
@item
|
|
@code{g77} currently inserts needless padding for things like
|
|
@samp{COMMON A,IPAD} where @samp{A} is @code{CHARACTER*1} and @samp{IPAD}
|
|
is @code{INTEGER(KIND=1)} on machines like x86,
|
|
because the back end insists that @samp{IPAD}
|
|
be aligned to a 4-byte boundary,
|
|
but the processor has no such requirement
|
|
(though it is usually good for performance).
|
|
|
|
The @code{gcc} back end needs to provide a wider array
|
|
of specifications of alignment requirements and preferences for targets,
|
|
and front ends like @code{g77} should take advantage of this
|
|
when it becomes available.
|
|
|
|
@cindex complex performance
|
|
@cindex aliasing
|
|
@item
|
|
The @code{libf2c} routines that perform some run-time
|
|
arithmetic on @code{COMPLEX} operands
|
|
were modified circa version 0.5.20 of @code{g77}
|
|
to work properly even in the presence of aliased operands.
|
|
|
|
While the @code{g77} and @code{netlib} versions of @code{libf2c}
|
|
differ on how this is accomplished,
|
|
the main differences are that we believe
|
|
the @code{g77} version works properly
|
|
even in the presence of @emph{partially} aliased operands.
|
|
|
|
However, these modifications have reduced performance
|
|
on targets such as x86,
|
|
due to the extra copies of operands involved.
|
|
@end itemize
|