1@c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. 2@c This is part of the G77 manual. 3@c For copying conditions, see the file g77.texi. 4 5@c The text of this file appears in the file BUGS 6@c in the G77 distribution, as well as in the G77 manual. 7 8@c Keep this the same as the dates above, since it's used 9@c in the standalone derivations of this file (e.g. BUGS). 10@set copyrights-bugs 1995,1996,1997,1998,1999,2000,2001,2002 11 12@set last-update-bugs 2002-02-01 13 14@ifset DOC-BUGS 15@include root.texi 16@c The immediately following lines apply to the BUGS file 17@c which is derived from this file. 18@emph{Note:} This file is automatically generated from the files 19@file{bugs0.texi} and @file{bugs.texi}. 20@file{BUGS} is @emph{not} a source file, 21although it is normally included within source distributions. 22 23This file lists known bugs in the @value{which-g77} version 24of the GNU Fortran compiler. 25Copyright (C) @value{copyrights-bugs} Free Software Foundation, Inc. 26You may copy, distribute, and modify it freely as long as you preserve 27this copyright notice and permission notice. 28 29@node Top,,, (dir) 30@chapter Known Bugs In GNU Fortran 31@end ifset 32 33@ifset DOC-G77 34@node Known Bugs 35@section Known Bugs In GNU Fortran 36@end ifset 37 38This section identifies bugs that @code{g77} @emph{users} 39might run into in the @value{which-g77} version 40of @code{g77}. 41This includes bugs that are actually in the @code{gcc} 42back end (GBE) or in @code{libf2c}, because those 43sets of code are at least somewhat under the control 44of (and necessarily intertwined with) @code{g77}, 45so it isn't worth separating them out. 46 47@ifset DOC-G77 48For information on bugs in @emph{other} versions of @code{g77}, 49see @ref{News,,News About GNU Fortran}. 50There, lists of bugs fixed in various versions of @code{g77} 51can help determine what bugs existed in prior versions. 52@end ifset 53 54@ifset DOC-BUGS 55For information on bugs in @emph{other} versions of @code{g77}, 56see @file{@value{path-g77}/NEWS}. 57There, lists of bugs fixed in various versions of @code{g77} 58can help determine what bugs existed in prior versions. 59@end ifset 60 61@ifset DEVELOPMENT 62@emph{Warning:} The information below is still under development, 63and might not accurately reflect the @code{g77} code base 64of which it is a part. 65Efforts are made to keep it somewhat up-to-date, 66but they are particularly concentrated 67on any version of this information 68that is distributed as part of a @emph{released} @code{g77}. 69 70In particular, while this information is intended to apply to 71the @value{which-g77} version of @code{g77}, 72only an official @emph{release} of that version 73is expected to contain documentation that is 74most consistent with the @code{g77} product in that version. 75@end ifset 76 77An online, ``live'' version of this document 78(derived directly from the mainline, development version 79of @code{g77} within @code{gcc}) 80is available via 81@uref{http://gcc.gnu.org/onlinedocs/g77/Trouble.html}. 82Follow the ``Known Bugs'' link. 83 84The following information was last updated on @value{last-update-bugs}: 85 86@itemize @bullet 87@item 88@code{g77} fails to warn about 89use of a ``live'' iterative-DO variable 90as an implied-DO variable 91in a @code{WRITE} or @code{PRINT} statement 92(although it does warn about this in a @code{READ} statement). 93 94@item 95Something about @code{g77}'s straightforward handling of 96label references and definitions sometimes prevents the GBE 97from unrolling loops. 98Until this is solved, try inserting or removing @code{CONTINUE} 99statements as the terminal statement, using the @code{END DO} 100form instead, and so on. 101 102@item 103Some confusion in diagnostics concerning failing @code{INCLUDE} 104statements from within @code{INCLUDE}'d or @code{#include}'d files. 105 106@cindex integer constants 107@cindex constants, integer 108@item 109@code{g77} assumes that @code{INTEGER(KIND=1)} constants range 110from @samp{-2**31} to @samp{2**31-1} (the range for 111two's-complement 32-bit values), 112instead of determining their range from the actual range of the 113type for the configuration (and, someday, for the constant). 114 115Further, it generally doesn't implement the handling 116of constants very well in that it makes assumptions about the 117configuration that it no longer makes regarding variables (types). 118 119Included with this item is the fact that @code{g77} doesn't recognize 120that, on IEEE-754/854-compliant systems, @samp{0./0.} should produce a NaN 121and no warning instead of the value @samp{0.} and a warning. 122 123@cindex compiler speed 124@cindex speed, of compiler 125@cindex compiler memory usage 126@cindex memory usage, of compiler 127@cindex large aggregate areas 128@cindex initialization, bug 129@cindex DATA statement 130@cindex statements, DATA 131@item 132@code{g77} uses way too much memory and CPU time to process large aggregate 133areas having any initialized elements. 134 135For example, @samp{REAL A(1000000)} followed by @samp{DATA A(1)/1/} 136takes up way too much time and space, including 137the size of the generated assembler file. 138 139Version 0.5.18 improves cases like this---specifically, 140cases of @emph{sparse} initialization that leave large, contiguous 141areas uninitialized---significantly. 142However, even with the improvements, these cases still 143require too much memory and CPU time. 144 145(Version 0.5.18 also improves cases where the initial values are 146zero to a much greater degree, so if the above example 147ends with @samp{DATA A(1)/0/}, the compile-time performance 148will be about as good as it will ever get, aside from unrelated 149improvements to the compiler.) 150 151Note that @code{g77} does display a warning message to 152notify the user before the compiler appears to hang. 153@ifset DOC-G77 154A warning message is issued when @code{g77} sees code that provides 155initial values (e.g. via @code{DATA}) to an aggregate area (@code{COMMON} 156or @code{EQUIVALENCE}, or even a large enough array or @code{CHARACTER} 157variable) 158that is large enough to increase @code{g77}'s compile time by roughly 159a factor of 10. 160 161This size currently is quite small, since @code{g77} 162currently has a known bug requiring too much memory 163and time to handle such cases. 164In @file{@value{path-g77}/data.c}, the macro 165@code{FFEDATA_sizeTOO_BIG_INIT_} is defined 166to the minimum size for the warning to appear. 167The size is specified in storage units, 168which can be bytes, words, or whatever, on a case-by-case basis. 169 170After changing this macro definition, you must 171(of course) rebuild and reinstall @code{g77} for 172the change to take effect. 173 174Note that, as of version 0.5.18, improvements have 175reduced the scope of the problem for @emph{sparse} 176initialization of large arrays, especially those 177with large, contiguous uninitialized areas. 178However, the warning is issued at a point prior to 179when @code{g77} knows whether the initialization is sparse, 180and delaying the warning could mean it is produced 181too late to be helpful. 182 183Therefore, the macro definition should not be adjusted to 184reflect sparse cases. 185Instead, adjust it to generate the warning when densely 186initialized arrays begin to cause responses noticeably slower 187than linear performance would suggest. 188@end ifset 189 190@cindex code, displaying main source 191@cindex displaying main source code 192@cindex debugging main source code 193@cindex printing main source 194@item 195When debugging, after starting up the debugger but before being able 196to see the source code for the main program unit, the user must currently 197set a breakpoint at @code{MAIN__} (or @code{MAIN___} or @code{MAIN_} if 198@code{MAIN__} doesn't exist) 199and run the program until it hits the breakpoint. 200At that point, the 201main program unit is activated and about to execute its first 202executable statement, but that's the state in which the debugger should 203start up, as is the case for languages like C. 204 205@cindex debugger 206@item 207Debugging @code{g77}-compiled code using debuggers other than 208@code{gdb} is likely not to work. 209 210Getting @code{g77} and @code{gdb} to work together is a known 211problem---getting @code{g77} to work properly with other 212debuggers, for which source code often is unavailable to @code{g77} 213developers, seems like a much larger, unknown problem, 214and is a lower priority than making @code{g77} and @code{gdb} 215work together properly. 216 217On the other hand, information about problems other debuggers 218have with @code{g77} output might make it easier to properly 219fix @code{g77}, and perhaps even improve @code{gdb}, so it 220is definitely welcome. 221Such information might even lead to all relevant products 222working together properly sooner. 223 224@cindex Alpha, support 225@cindex support, Alpha 226@item 227@code{g77} doesn't work perfectly on 64-bit configurations 228such as the Digital Semiconductor (``DEC'') Alpha. 229 230This problem is largely resolved as of version 0.5.23. 231 232@cindex padding 233@cindex structures 234@cindex common blocks 235@cindex equivalence areas 236@item 237@code{g77} currently inserts needless padding for things like 238@samp{COMMON A,IPAD} where @samp{A} is @code{CHARACTER*1} and @samp{IPAD} 239is @code{INTEGER(KIND=1)} on machines like x86, 240because the back end insists that @samp{IPAD} 241be aligned to a 4-byte boundary, 242but the processor has no such requirement 243(though it is usually good for performance). 244 245The @code{gcc} back end needs to provide a wider array 246of specifications of alignment requirements and preferences for targets, 247and front ends like @code{g77} should take advantage of this 248when it becomes available. 249 250@cindex complex performance 251@cindex aliasing 252@item 253The @code{libf2c} routines that perform some run-time 254arithmetic on @code{COMPLEX} operands 255were modified circa version 0.5.20 of @code{g77} 256to work properly even in the presence of aliased operands. 257 258While the @code{g77} and @code{netlib} versions of @code{libf2c} 259differ on how this is accomplished, 260the main differences are that we believe 261the @code{g77} version works properly 262even in the presence of @emph{partially} aliased operands. 263 264However, these modifications have reduced performance 265on targets such as x86, 266due to the extra copies of operands involved. 267@end itemize 268