1 @c Copyright (C) 1995-1998 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.
12 @section Actual Bugs We Haven't Fixed Yet
15 This section identifies bugs that @code{g77} @emph{users}
17 This includes bugs that are actually in the @code{gcc}
18 back end (GBE) or in @code{libf2c}, because those
19 sets of code are at least somewhat under the control
20 of (and necessarily intertwined with) @code{g77}, so it
21 isn't worth separating them out.
23 For information on bugs that might afflict people who
24 configure, port, build, and install @code{g77},
25 @ref{Problems Installing}.
29 @code{g77} sometimes crashes when compiling code
30 containing the construct @samp{CMPLX(0.)} or similar.
31 This is a @code{gcc} back-end bug.
32 It can be worked around using @samp{-fno-emulate-complex},
33 though that might trigger other, older bugs.
34 Compiling without optimization is another work-around.
36 Fixed in @code{egcs} 1.1.
39 @c Tim Prince discovered this.
40 Automatic arrays aren't working on HP-UX systems,
41 at least in HP-UX version 10.20.
42 Writing into them apparently causes over-writing
43 of statically declared data in the main program.
44 This probably means the arrays themselves are being under-allocated,
45 or pointers to them being improperly handled,
46 e.g. not passed to other procedures as they should be.
49 @c Toon Moene discovered these.
50 Some Fortran code has been found to be miscompiled
51 by @code{g77} built on @code{gcc} version 2.8.1
52 on m68k-next-nextstep3 configurations
53 when using the @samp{-O2} option.
54 Even a C function is known to miscompile
56 when using the @samp{-O2 -funroll-loops} options.
61 @cindex stack, 387 coprocessor
66 A code-generation bug afflicts
67 Intel x86 targets when @samp{-O2} is specified
68 compiling, for example, an old version of
69 the @samp{DNRM2} routine.
70 The x87 coprocessor stack is being
71 mismanaged in cases where assigned @code{GOTO}
72 and @code{ASSIGN} are involved.
74 Fixed in @code{egcs} version 1.1.
77 @code{g77} fails to warn about
78 use of a ``live'' iterative-DO variable
79 as an implied-DO variable
80 in a @samp{WRITE} or @samp{PRINT} statement
81 (although it does warn about this in a @samp{READ} statement).
84 A compiler crash, or apparently infinite run time,
85 can result when compiling complicated expressions
86 involving @code{COMPLEX} arithmetic
87 (especially multiplication).
89 Fixed in @code{egcs} version 1.1.
92 Something about @code{g77}'s straightforward handling of
93 label references and definitions sometimes prevents the GBE
95 Until this is solved, try inserting or removing @code{CONTINUE}
96 statements as the terminal statement, using the @code{END DO}
97 form instead, and so on.
100 Some confusion in diagnostics concerning failing @code{INCLUDE}
101 statements from within @code{INCLUDE}'d or @code{#include}'d files.
103 @cindex integer constants
104 @cindex constants, integer
106 @code{g77} assumes that @code{INTEGER(KIND=1)} constants range
107 from @samp{-2**31} to @samp{2**31-1} (the range for
108 two's-complement 32-bit values),
109 instead of determining their range from the actual range of the
110 type for the configuration (and, someday, for the constant).
112 Further, it generally doesn't implement the handling
113 of constants very well in that it makes assumptions about the
114 configuration that it no longer makes regarding variables (types).
116 Included with this item is the fact that @code{g77} doesn't recognize
117 that, on IEEE-754/854-compliant systems, @samp{0./0.} should produce a NaN
118 and no warning instead of the value @samp{0.} and a warning.
119 This is to be fixed in version 0.6, when @code{g77} will use the
120 @code{gcc} back end's constant-handling mechanisms to replace its own.
122 @cindex compiler speed
123 @cindex speed, of compiler
124 @cindex compiler memory usage
125 @cindex memory usage, of compiler
126 @cindex large aggregate areas
127 @cindex initialization, bug
128 @cindex DATA statement
129 @cindex statements, DATA
131 @code{g77} uses way too much memory and CPU time to process large aggregate
132 areas having any initialized elements.
134 For example, @samp{REAL A(1000000)} followed by @samp{DATA A(1)/1/}
135 takes up way too much time and space, including
136 the size of the generated assembler file.
137 This is to be mitigated somewhat in version 0.6.
139 Version 0.5.18 improves cases like this---specifically,
140 cases of @emph{sparse} initialization that leave large, contiguous
141 areas uninitialized---significantly.
142 However, even with the improvements, these cases still
143 require too much memory and CPU time.
145 (Version 0.5.18 also improves cases where the initial values are
146 zero to a much greater degree, so if the above example
147 ends with @samp{DATA A(1)/0/}, the compile-time performance
148 will be about as good as it will ever get, aside from unrelated
149 improvements to the compiler.)
151 Note that @code{g77} does display a warning message to
152 notify the user before the compiler appears to hang.
153 @xref{Large Initialization,,Initialization of Large Aggregate Areas},
154 for information on how to change the point at which
155 @code{g77} decides to issue this warning.
158 @cindex common blocks
159 @cindex equivalence areas
160 @cindex local equivalence areas
162 @code{g77} doesn't emit variable and array members of common blocks for use
163 with a debugger (the @samp{-g} command-line option).
164 The code is present to do this, but doesn't work with at least
165 one debug format---perhaps it works with others.
166 And it turns out there's a similar bug for
167 local equivalence areas, so that has been disabled as well.
169 As of Version 0.5.19, a temporary kludge solution is provided whereby
170 some rudimentary information on a member is written as a string that
171 is the member's value as a character string.
173 @xref{Code Gen Options,,Options for Code Generation Conventions},
174 for information on the @samp{-fdebug-kludge} option.
176 @cindex code, displaying main source
177 @cindex displaying main source code
178 @cindex debugging main source code
179 @cindex printing main source
181 When debugging, after starting up the debugger but before being able
182 to see the source code for the main program unit, the user must currently
183 set a breakpoint at @samp{MAIN__} (or @samp{MAIN___} or @samp{MAIN_} if
184 @samp{MAIN__} doesn't exist)
185 and run the program until it hits the breakpoint.
187 main program unit is activated and about to execute its first
188 executable statement, but that's the state in which the debugger should
189 start up, as is the case for languages like C.
193 Debugging @code{g77}-compiled code using debuggers other than
194 @code{gdb} is likely not to work.
196 Getting @code{g77} and @code{gdb} to work together is a known
197 problem---getting @code{g77} to work properly with other
198 debuggers, for which source code often is unavailable to @code{g77}
199 developers, seems like a much larger, unknown problem,
200 and is a lower priority than making @code{g77} and @code{gdb}
201 work together properly.
203 On the other hand, information about problems other debuggers
204 have with @code{g77} output might make it easier to properly
205 fix @code{g77}, and perhaps even improve @code{gdb}, so it
206 is definitely welcome.
207 Such information might even lead to all relevant products
208 working together properly sooner.
210 @cindex Alpha, support
211 @cindex support, Alpha
213 @code{g77} doesn't work perfectly on 64-bit configurations
214 such as the Digital Semiconductor (``DEC'') Alpha.
216 This problem is largely resolved as of version 0.5.23.
217 Version 0.6 should solve most or all remaining problems
218 (such as cross-compiling involving 64-bit machines).
220 @cindex COMPLEX support
221 @cindex support, COMPLEX
223 Maintainers of @code{gcc} report that the back end definitely has ``broken''
224 support for @code{COMPLEX} types.
225 Based on their input, it seems many of
226 the problems affect only the more-general facilities for gcc's
227 @code{__complex__} type, such as @code{__complex__ int}
228 (where the real and imaginary parts are integers) that GNU
229 Fortran does not use.
231 Version 0.5.20 of @code{g77} works around this
232 problem by not using the back end's support for @code{COMPLEX}.
233 The new option @samp{-fno-emulate-complex} avoids the work-around,
234 reverting to using the same ``broken'' mechanism as that used
235 by versions of @code{g77} prior to 0.5.20.
240 @cindex options, -fPIC
242 @code{g77} sometimes produces invalid assembler code
243 when using the @samp{-fPIC} option (such as compiling for ELF targets)
244 on the Intel x86 architecture target.
245 The symptom is that the assembler complains about invalid opcodes.
246 This bug is in the @code{gcc} back end.
248 Fixed in @code{egcs} version 1.0.2.
252 @cindex common blocks
253 @cindex equivalence areas
255 @code{g77} currently inserts needless padding for things like
256 @samp{COMMON A,IPAD} where @samp{A} is @code{CHARACTER*1} and @samp{IPAD}
257 is @code{INTEGER(KIND=1)} on machines like x86,
258 because the back end insists that @samp{IPAD}
259 be aligned to a 4-byte boundary,
260 but the processor has no such requirement
261 (though it is usually good for performance).
263 The @code{gcc} back end needs to provide a wider array
264 of specifications of alignment requirements and preferences for targets,
265 and front ends like @code{g77} should take advantage of this
266 when it becomes available.
269 @cindex double-precision performance
270 @cindex -malign-double
272 The x86 target's @samp{-malign-double} option
273 no longer reliably aligns double-precision variables and arrays
274 when they are placed in the stack frame.
276 This can significantly reduce the performance of some applications,
277 even on a run-to-run basis
278 (that is, performance measurements can vary fairly widely
279 depending on whether frequently used variables are properly aligned,
280 and that can change from one program run to the next,
281 even from one procedure call to the next).
283 Versions 0.5.22 and earlier of @code{g77}
284 included a patch to @code{gcc} that enabled this,
285 but that patch has been deemed an improper (probably buggy) one
286 for version 2.8 of @code{gcc} and for @code{egcs}.
288 Note that version 1.1 of @code{egcs}
289 aligns double-precision variables and arrays
290 when they are in static storage
291 even if @samp{-malign-double} is not specified.
293 There is ongoing investigation into
294 how to make @samp{-malign-double} work properly,
295 also into how to make it unnecessary to get
296 all double-precision variables and arrays aligned
297 when such alignment would not violate
298 the relevant specifications for processor
299 and inter-procedural interfaces.
301 For a suite of programs to test double-precision alignment,
302 see @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
304 @cindex complex performance
307 The @code{libf2c} routines that perform some run-time
308 arithmetic on @code{COMPLEX} operands
309 were modified circa version 0.5.20 of @code{g77}
310 to work properly even in the presence of aliased operands.
312 While the @code{g77} and @code{netlib} versions of @code{libf2c}
313 differ on how this is accomplished,
314 the main differences are that we believe
315 the @code{g77} version works properly
316 even in the presence of @emph{partially} aliased operands.
318 However, these modifications have reduced performance
319 on targets such as x86,
320 due to the extra copies of operands involved.