X-Git-Url: http://git.sourceforge.jp/view?p=pf3gnuchains%2Fgcc-fork.git;a=blobdiff_plain;f=gcc%2Ff%2Fbugs.texi;h=bdd87651d8a970f60ccf8bb78ded0716657db89e;hp=4fb96303c8bb2edbbff63c978f8b094d665c93a5;hb=afbc17f2fe89343c2f32ee1178862a38dedf7b2c;hpb=1a248bc5fdaace77ebd534558faf2f1769f9c83b diff --git a/gcc/f/bugs.texi b/gcc/f/bugs.texi index 4fb96303c8b..bdd87651d8a 100644 --- a/gcc/f/bugs.texi +++ b/gcc/f/bugs.texi @@ -1,44 +1,96 @@ -@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 @@ -47,13 +99,6 @@ 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. -(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} @@ -75,15 +120,13 @@ 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. -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 @@ -93,7 +136,6 @@ 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. -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 @@ -109,28 +151,42 @@ improvements to the compiler.) 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 @@ -139,8 +195,8 @@ for information on the @samp{-fdebug-kludge} option. @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 @@ -166,6 +222,14 @@ 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 @@ -173,72 +237,32 @@ working together properly sooner. @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