gcc/f/BUGS

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