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
65 A code-generation bug afflicts
66 Intel x86 targets when @samp{-O2} is specified
67 compiling, for example, an old version of
68 the @samp{DNRM2} routine.
69 The x87 coprocessor stack is being
70 mismanaged in cases where assigned @code{GOTO}
71 and @code{ASSIGN} are involved.
73 Fixed in @code{egcs} version 1.1.
76 @code{g77} fails to warn about
77 use of a ``live'' iterative-DO variable
78 as an implied-DO variable
79 in a @samp{WRITE} or @samp{PRINT} statement
80 (although it does warn about this in a @samp{READ} statement).
83 A compiler crash, or apparently infinite run time,
84 can result when compiling complicated expressions
85 involving @code{COMPLEX} arithmetic
86 (especially multiplication).
88 Fixed in @code{egcs} version 1.1.
91 Something about @code{g77}'s straightforward handling of
92 label references and definitions sometimes prevents the GBE
94 Until this is solved, try inserting or removing @code{CONTINUE}
95 statements as the terminal statement, using the @code{END DO}
96 form instead, and so on.
99 Some confusion in diagnostics concerning failing @code{INCLUDE}
100 statements from within @code{INCLUDE}'d or @code{#include}'d files.
102 @cindex integer constants
103 @cindex constants, integer
105 @code{g77} assumes that @code{INTEGER(KIND=1)} constants range
106 from @samp{-2**31} to @samp{2**31-1} (the range for
107 two's-complement 32-bit values),
108 instead of determining their range from the actual range of the
109 type for the configuration (and, someday, for the constant).
111 Further, it generally doesn't implement the handling
112 of constants very well in that it makes assumptions about the
113 configuration that it no longer makes regarding variables (types).
115 Included with this item is the fact that @code{g77} doesn't recognize
116 that, on IEEE-754/854-compliant systems, @samp{0./0.} should produce a NaN
117 and no warning instead of the value @samp{0.} and a warning.
118 This is to be fixed in version 0.6, when @code{g77} will use the
119 @code{gcc} back end's constant-handling mechanisms to replace its own.
121 @cindex compiler speed
122 @cindex speed, of compiler
123 @cindex compiler memory usage
124 @cindex memory usage, of compiler
125 @cindex large aggregate areas
126 @cindex initialization
127 @cindex DATA statement
128 @cindex statements, DATA
130 @code{g77} uses way too much memory and CPU time to process large aggregate
131 areas having any initialized elements.
133 For example, @samp{REAL A(1000000)} followed by @samp{DATA A(1)/1/}
134 takes up way too much time and space, including
135 the size of the generated assembler file.
136 This is to be mitigated somewhat in version 0.6.
138 Version 0.5.18 improves cases like this---specifically,
139 cases of @emph{sparse} initialization that leave large, contiguous
140 areas uninitialized---significantly.
141 However, even with the improvements, these cases still
142 require too much memory and CPU time.
144 (Version 0.5.18 also improves cases where the initial values are
145 zero to a much greater degree, so if the above example
146 ends with @samp{DATA A(1)/0/}, the compile-time performance
147 will be about as good as it will ever get, aside from unrelated
148 improvements to the compiler.)
150 Note that @code{g77} does display a warning message to
151 notify the user before the compiler appears to hang.
152 @xref{Large Initialization,,Initialization of Large Aggregate Areas},
153 for information on how to change the point at which
154 @code{g77} decides to issue this warning.
157 @cindex common blocks
158 @cindex equivalence areas
159 @cindex local equivalence areas
161 @code{g77} doesn't emit variable and array members of common blocks for use
162 with a debugger (the @samp{-g} command-line option).
163 The code is present to do this, but doesn't work with at least
164 one debug format---perhaps it works with others.
165 And it turns out there's a similar bug for
166 local equivalence areas, so that has been disabled as well.
168 As of Version 0.5.19, a temporary kludge solution is provided whereby
169 some rudimentary information on a member is written as a string that
170 is the member's value as a character string.
172 @xref{Code Gen Options,,Options for Code Generation Conventions},
173 for information on the @samp{-fdebug-kludge} option.
175 @cindex code, displaying main source
176 @cindex displaying main source code
177 @cindex debugging main source code
178 @cindex printing main source
180 When debugging, after starting up the debugger but before being able
181 to see the source code for the main program unit, the user must currently
182 set a breakpoint at @samp{MAIN__} (or @samp{MAIN___} or @samp{MAIN_} if
183 @samp{MAIN__} doesn't exist)
184 and run the program until it hits the breakpoint.
186 main program unit is activated and about to execute its first
187 executable statement, but that's the state in which the debugger should
188 start up, as is the case for languages like C.
192 Debugging @code{g77}-compiled code using debuggers other than
193 @code{gdb} is likely not to work.
195 Getting @code{g77} and @code{gdb} to work together is a known
196 problem---getting @code{g77} to work properly with other
197 debuggers, for which source code often is unavailable to @code{g77}
198 developers, seems like a much larger, unknown problem,
199 and is a lower priority than making @code{g77} and @code{gdb}
200 work together properly.
202 On the other hand, information about problems other debuggers
203 have with @code{g77} output might make it easier to properly
204 fix @code{g77}, and perhaps even improve @code{gdb}, so it
205 is definitely welcome.
206 Such information might even lead to all relevant products
207 working together properly sooner.
209 @cindex Alpha, support
210 @cindex support, Alpha
212 @code{g77} doesn't work perfectly on 64-bit configurations
213 such as the Digital Semiconductor (``DEC'') Alpha.
215 This problem is largely resolved as of version 0.5.23.
216 Version 0.6 should solve most or all remaining problems
217 (such as cross-compiling involving 64-bit machines).
219 @cindex COMPLEX support
220 @cindex support, COMPLEX
222 Maintainers of gcc report that the back end definitely has ``broken''
223 support for @code{COMPLEX} types.
224 Based on their input, it seems many of
225 the problems affect only the more-general facilities for gcc's
226 @code{__complex__} type, such as @code{__complex__ int}
227 (where the real and imaginary parts are integers) that GNU
228 Fortran does not use.
230 Version 0.5.20 of @code{g77} works around this
231 problem by not using the back end's support for @code{COMPLEX}.
232 The new option @samp{-fno-emulate-complex} avoids the work-around,
233 reverting to using the same ``broken'' mechanism as that used
234 by versions of @code{g77} prior to 0.5.20.
239 @cindex options, -fPIC
241 @code{g77} sometimes produces invalid assembler code
242 when using the @samp{-fPIC} option (such as compiling for ELF targets)
243 on the Intel x86 architecture target.
244 The symptom is that the assembler complains about invalid opcodes.
245 This bug is in the gcc back end.
247 Fixed in @code{egcs} version 1.0.2.
251 @cindex common blocks
252 @cindex equivalence areas
254 @code{g77} currently inserts needless padding for things like
255 @samp{COMMON A,IPAD} where @samp{A} is @code{CHARACTER*1} and @samp{IPAD}
256 is @code{INTEGER(KIND=1)} on machines like x86,
257 because the back end insists that @samp{IPAD}
258 be aligned to a 4-byte boundary,
259 but the processor has no such requirement
260 (though it is usually good for performance).
262 The @code{gcc} back end needs to provide a wider array
263 of specifications of alignment requirements and preferences for targets,
264 and front ends like @code{g77} should take advantage of this
265 when it becomes available.
268 @cindex double-precision performance
269 @cindex -malign-double
271 The x86 target's @samp{-malign-double} option
272 no longer reliably aligns double-precision variables and arrays
273 when they are placed in the stack frame.
275 This can significantly reduce the performance of some applications,
276 even on a run-to-run basis
277 (that is, performance measurements can vary fairly widely
278 depending on whether frequently used variables are properly aligned,
279 and that can change from one program run to the next,
280 even from one procedure call to the next).
282 Versions 0.5.22 and earlier of @code{g77}
283 included a patch to @code{gcc} that enabled this,
284 but that patch has been deemed an improper (probably buggy) one
285 for version 2.8 of @code{gcc} and for @code{egcs}.
287 Note that version 1.1 of @code{egcs}
288 aligns double-precision variables and arrays
289 when they are in static storage
290 even if @samp{-malign-double} is not specified.
292 There is ongoing investigation into
293 how to make @samp{-malign-double} work properly,
294 also into how to make it unnecessary to get
295 all double-precision variables and arrays aligned
296 when such alignment would not violate
297 the relevant specifications for processor
298 and inter-procedural interfaces.
300 For a suite of programs to test double-precision alignment,
301 see @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
303 @cindex complex performance
306 The @code{libf2c} routines that perform some run-time
307 arithmetic on @code{COMPLEX} operands
308 were modified circa version 0.5.20 of @code{g77}
309 to work properly even in the presence of aliased operands.
311 While the @code{g77} and @code{netlib} versions of @code{libf2c}
312 differ on how this is accomplished,
313 the main differences are that we believe
314 the @code{g77} version works properly
315 even in the presence of @emph{partially} aliased operands.
317 However, these modifications have reduced performance
318 on targets such as x86,
319 due to the extra copies of operands involved.