gcc/f/bugs.texi

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