-@c Copyright (C) 1995-1998 Free Software Foundation, Inc.
+@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 1998-03-15
+@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
-@ifclear BUGSONLY
-@node Actual Bugs
-@section Actual Bugs We Haven't Fixed Yet
-@end ifclear
+@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.
+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.
-
-For information on bugs that might afflict people who
-configure, port, build, and install @code{g77},
-@ref{Problems Installing}.
+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
-@cindex Alpha
-@cindex -O2
@item
-@code{g77}'s version of @code{gcc}, and probably @code{g77}
-itself, cannot be reliably used with the @samp{-O2} option
-(or higher) on Digital Semiconductor Alpha AXP machines.
-The problem is most immediately noticed in differences
-discovered by @kbd{make compare} following a bootstrap
-build using @samp{-O2}.
-It also manifests itself as a failure to compile
-@samp{DATA} statements such as @samp{DATA R/7./} correctly;
-in this case, @samp{R} might be initialized to @samp{4.0}.
-
-Until this bug is fixed, use only @samp{-O1} or no optimization.
+@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
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.
-(Probably improved, but not wholly fixed, in 0.5.21.)
-
-@item
-The @code{g77} command itself should more faithfully process
-options the way the @code{gcc} command does.
-For example, @code{gcc} accepts abbreviated forms of long options,
-@code{g77} generally doesn't.
@item
Some confusion in diagnostics concerning failing @code{INCLUDE}
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.
-This is to be fixed in version 0.6, when @code{g77} will use the
-@code{gcc} back end's constant-handling mechanisms to replace its own.
@cindex compiler speed
@cindex speed, of compiler
@cindex compiler memory usage
@cindex memory usage, of compiler
@cindex large aggregate areas
-@cindex initialization
+@cindex initialization, bug
@cindex DATA statement
@cindex statements, DATA
@item
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.
-This is to be mitigated somewhat in version 0.6.
Version 0.5.18 improves cases like this---specifically,
cases of @emph{sparse} initialization that leave large, contiguous
Note that @code{g77} does display a warning message to
notify the user before the compiler appears to hang.
-@xref{Large Initialization,,Initialization of Large Aggregate Areas},
-for information on how to change the point at which
-@code{g77} decides to issue this warning.
-
-@cindex debugging
-@cindex common blocks
-@cindex equivalence areas
-@cindex local equivalence areas
-@item
-@code{g77} doesn't emit variable and array members of common blocks for use
-with a debugger (the @samp{-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.
-
-As of Version 0.5.19, a temporary kludge solution is provided whereby
-some rudimentary information on a member is written as a string that
-is the member's value as a character string.
-
-@xref{Code Gen Options,,Options for Code Generation Conventions},
-for information on the @samp{-fdebug-kludge} option.
+@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
@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 @samp{MAIN__} (or @samp{MAIN___} or @samp{MAIN_} if
-@samp{MAIN__} doesn't exist)
+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
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
@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'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 @code{g77} and other
-compilers.
-
-@cindex Alpha, support
-@cindex support, Alpha
-@item
-@code{g77} doesn't work perfectly on 64-bit configurations such as the Alpha.
-This problem is expected to be largely resolved as of version 0.5.20,
-and further addressed by 0.5.21.
-Version 0.6 should solve most or all related problems (such as
-64-bit machines other than Digital Semiconductor (``DEC'') Alphas).
-
-One known bug that causes a compile-time crash occurs when compiling
-code such as the following with optimization:
-
-@example
-SUBROUTINE CRASH (TEMP)
-INTEGER*2 HALF(2)
-REAL TEMP
-HALF(1) = NINT (TEMP)
-END
-@end example
-
-It is expected that a future version of @code{g77} will have a fix for this
-problem, almost certainly by the time @code{g77} supports the forthcoming
-version 2.8.0 of @code{gcc}.
-
-@cindex COMPLEX support
-@cindex support, COMPLEX
-@item
-Maintainers of gcc report that the back end definitely has ``broken''
-support for @code{COMPLEX} types.
-Based on their input, it seems many of
-the problems affect only the more-general facilities for gcc's
-@code{__complex__} type, such as @code{__complex__ int}
-(where the real and imaginary parts are integers) that GNU
-Fortran does not use.
-
-Version 0.5.20 of @code{g77} works around this
-problem by not using the back end's support for @code{COMPLEX}.
-The new option @samp{-fno-emulate-complex} avoids the work-around,
-reverting to using the same ``broken'' mechanism as that used
-by versions of @code{g77} prior to 0.5.20.
-
-@cindex ELF support
-@cindex support, ELF
-@cindex -fPIC option
-@cindex options, -fPIC
+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
-There seem to be some problems with passing constants, and perhaps
-general expressions (other than simple variables/arrays), to procedures
-when compiling on some systems (such as i386) with @samp{-fPIC}, as in
-when compiling for ELF targets.
-The symptom is that the assembler complains about invalid opcodes.
-This bug is in the gcc back end,
-and it apparently occurs only when
-compiling sufficiently complicated functions @emph{without} the
-@samp{-O} option.
+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
OSDN Git Service
