-@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-09-01
+@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
-This section identifies bugs that @code{g77} @emph{users}
-might run into.
-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.
+@include root.texi
-For information on bugs that might afflict people who
-configure, port, build, and install @code{g77},
-@ref{Problems Installing}.
+@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.
-@itemize @bullet
-@item
-@code{g77} sometimes crashes when compiling code
-containing the construct @samp{CMPLX(0.)} or similar.
-This is a @code{gcc} back-end bug.
-It can be worked around using @samp{-fno-emulate-complex},
-though that might trigger other, older bugs.
-Compiling without optimization is another work-around.
+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.
-Fixed in @code{egcs} 1.1.
+@node Top,,, (dir)
+@chapter Known Bugs In GNU Fortran
+@end ifset
-@item
-@c Tim Prince discovered this.
-Automatic arrays aren't working on HP-UX systems,
-at least in HP-UX version 10.20.
-Writing into them apparently causes over-writing
-of statically declared data in the main program.
-This probably means the arrays themselves are being under-allocated,
-or pointers to them being improperly handled,
-e.g. not passed to other procedures as they should be.
+@ifset DOC-G77
+@node Known Bugs
+@section Known Bugs In GNU Fortran
+@end ifset
-@item
-@c Toon Moene discovered these.
-Some Fortran code has been found to be miscompiled
-by @code{g77} built on @code{gcc} version 2.8.1
-on m68k-next-nextstep3 configurations
-when using the @samp{-O2} option.
-Even a C function is known to miscompile
-on that configuration
-when using the @samp{-O2 -funroll-loops} options.
-
-Fixed in @code{egcs}.
-
-@cindex DNRM2
-@cindex stack, 387 coprocessor
-@cindex ix86
-@cindex -O2
-@item
-A code-generation bug afflicts
-Intel x86 targets when @samp{-O2} is specified
-compiling, for example, an old version of
-the @samp{DNRM2} routine.
-The x87 coprocessor stack is being
-mismanaged in cases where assigned @code{GOTO}
-and @code{ASSIGN} are involved.
-
-Fixed in @code{egcs} version 1.1.
+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 @samp{WRITE} or @samp{PRINT} statement
-(although it does warn about this in a @samp{READ} statement).
-
-@item
-A compiler crash, or apparently infinite run time,
-can result when compiling complicated expressions
-involving @code{COMPLEX} arithmetic
-(especially multiplication).
-
-Fixed in @code{egcs} version 1.1.
+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
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 as the Digital Semiconductor (``DEC'') Alpha.
This problem is largely resolved as of version 0.5.23.
-Version 0.6 should solve most or all remaining problems
-(such as cross-compiling involving 64-bit machines).
-
-@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
-@item
-@code{g77} sometimes produces invalid assembler code
-when using the @samp{-fPIC} option (such as compiling for ELF targets)
-on the Intel x86 architecture target.
-The symptom is that the assembler complains about invalid opcodes.
-This bug is in the gcc back end.
-
-Fixed in @code{egcs} version 1.0.2.
@cindex padding
@cindex structures
and front ends like @code{g77} should take advantage of this
when it becomes available.
-@cindex alignment
-@cindex double-precision performance
-@cindex -malign-double
-@item
-The x86 target's @samp{-malign-double} option
-no longer reliably aligns double-precision variables and arrays
-when they are placed in the stack frame.
-
-This can significantly reduce the performance of some applications,
-even on a run-to-run basis
-(that is, performance measurements can vary fairly widely
-depending on whether frequently used variables are properly aligned,
-and that can change from one program run to the next,
-even from one procedure call to the next).
-
-Versions 0.5.22 and earlier of @code{g77}
-included a patch to @code{gcc} that enabled this,
-but that patch has been deemed an improper (probably buggy) one
-for version 2.8 of @code{gcc} and for @code{egcs}.
-
-Note that version 1.1 of @code{egcs}
-aligns double-precision variables and arrays
-when they are in static storage
-even if @samp{-malign-double} is not specified.
-
-There is ongoing investigation into
-how to make @samp{-malign-double} work properly,
-also into how to make it unnecessary to get
-all double-precision variables and arrays aligned
-when such alignment would not violate
-the relevant specifications for processor
-and inter-procedural interfaces.
-
-For a suite of programs to test double-precision alignment,
-see @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
-
@cindex complex performance
@cindex aliasing
@item
OSDN Git Service
