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