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