X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=blobdiff_plain;f=gcc%2Ff%2Fbugs.texi;fp=gcc%2Ff%2Fbugs.texi;h=0000000000000000000000000000000000000000;hb=6fed43773c9b0ce596dca5686f37ac3fc0fa11c0;hp=bdd87651d8a970f60ccf8bb78ded0716657db89e;hpb=27b11d56b743098deb193d510b337ba22dc52e5c;p=msp430-gcc.git

diff --git a/gcc/f/bugs.texi b/gcc/f/bugs.texi
deleted file mode 100644
index bdd87651..00000000
--- a/gcc/f/bugs.texi
+++ /dev/null
@@ -1,268 +0,0 @@
-@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