[pf3gnuchains/gcc-fork.git] / gcc / f / bugs.texi

@c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001 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

@set last-update-bugs 2002-02-01

@include root.texi

@ifset DOC-BUGS
@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

An online, ``live'' version of this document
(derived directly from the mainline, development version
of @code{g77} within @code{gcc})
is available via
@uref{http://www.gnu.org/software/gcc/onlinedocs/g77/Trouble.html}.
Follow the ``Known Bugs'' link.

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