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    * Work is needed on the `SIGNAL()' intrinsic to ensure that pointers
  19      and integers are properly handled on all targets, including 64-bit
  20      machines.
  21
  22    * When using `-fugly-comma', `g77' assumes an extra `%VAL(0)'
  23      argument is to be passed to intrinsics taking no arguments, such
  24      as `IARGC()', which in turn reject such a call.  Although this has
  25      been worked around for 0.5.18 due to changes in the handling of
  26      intrinsics, `g77' needs to do the ugly-argument-appending trick
  27      only for external-function invocation, as this would probably be
  28      more consistent with compilers that default to using that trick.
  29
  30    * Something about `g77''s straightforward handling of label
  31      references and definitions sometimes prevents the GBE from
  32      unrolling loops.  Until this is solved, try inserting or removing
  33      `CONTINUE' statements as the terminal statement, using the `END DO'
  34      form instead, and so on.  (Probably improved, but not wholly
  35      fixed, in 0.5.21.)
  36
  37    * The `g77' command itself should more faithfully process options
  38      the way the `gcc' command does.  For example, `gcc' accepts
  39      abbreviated forms of long options, `g77' generally doesn't.
  40
  41    * Some confusion in diagnostics concerning failing `INCLUDE'
  42      statements from within `INCLUDE''d or `#include''d files.
  43
  44    * `g77' assumes that `INTEGER(KIND=1)' constants range from `-2**31'
  45      to `2**31-1' (the range for two's-complement 32-bit values),
  46      instead of determining their range from the actual range of the
  47      type for the configuration (and, someday, for the constant).
  48
  49      Further, it generally doesn't implement the handling of constants
  50      very well in that it makes assumptions about the configuration
  51      that it no longer makes regarding variables (types).
  52
  53      Included with this item is the fact that `g77' doesn't recognize
  54      that, on IEEE-754/854-compliant systems, `0./0.' should produce a
  55      NaN and no warning instead of the value `0.' and a warning.  This
  56      is to be fixed in version 0.6, when `g77' will use the `gcc' back
  57      end's constant-handling mechanisms to replace its own.
  58
  59    * `g77' uses way too much memory and CPU time to process large
  60      aggregate areas having any initialized elements.
  61
  62      For example, `REAL A(1000000)' followed by `DATA A(1)/1/' takes up
  63      way too much time and space, including the size of the generated
  64      assembler file.  This is to be mitigated somewhat in version 0.6.
  65
  66      Version 0.5.18 improves cases like this--specifically, cases of
  67      *sparse* initialization that leave large, contiguous areas
  68      uninitialized--significantly.  However, even with the
  69      improvements, these cases still require too much memory and CPU
  70      time.
  71
  72      (Version 0.5.18 also improves cases where the initial values are
  73      zero to a much greater degree, so if the above example ends with
  74      `DATA A(1)/0/', the compile-time performance will be about as good
  75      as it will ever get, aside from unrelated improvements to the
  76      compiler.)
  77
  78      Note that `g77' does display a warning message to notify the user
  79      before the compiler appears to hang.  *Note Initialization of
  80      Large Aggregate Areas: Large Initialization, for information on
  81      how to change the point at which `g77' decides to issue this
  82      warning.
  83
  84    * `g77' doesn't emit variable and array members of common blocks for
  85      use with a debugger (the `-g' command-line option).  The code is
  86      present to do this, but doesn't work with at least one debug
  87      format--perhaps it works with others.  And it turns out there's a
  88      similar bug for local equivalence areas, so that has been disabled
  89      as well.
  90
  91      As of Version 0.5.19, a temporary kludge solution is provided
  92      whereby some rudimentary information on a member is written as a
  93      string that is the member's value as a character string.
  94
  95      *Note Options for Code Generation Conventions: Code Gen Options,
  96      for information on the `-fdebug-kludge' option.
  97
  98    * When debugging, after starting up the debugger but before being
  99      able to see the source code for the main program unit, the user
 100      must currently set a breakpoint at `MAIN__' (or `MAIN___' or
 101      `MAIN_' if `MAIN__' doesn't exist) and run the program until it
 102      hits the breakpoint.  At that point, the main program unit is
 103      activated and about to execute its first executable statement, but
 104      that's the state in which the debugger should start up, as is the
 105      case for languages like C.
 106
 107    * Debugging `g77'-compiled code using debuggers other than `gdb' is
 108      likely not to work.
 109
 110      Getting `g77' and `gdb' to work together is a known
 111      problem--getting `g77' to work properly with other debuggers, for
 112      which source code often is unavailable to `g77' developers, seems
 113      like a much larger, unknown problem, and is a lower priority than
 114      making `g77' and `gdb' work together properly.
 115
 116      On the other hand, information about problems other debuggers have
 117      with `g77' output might make it easier to properly fix `g77', and
 118      perhaps even improve `gdb', so it is definitely welcome.  Such
 119      information might even lead to all relevant products working
 120      together properly sooner.
 121
 122    * `g77' currently inserts needless padding for things like `COMMON
 123      A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER(KIND=1)'
 124      on machines like x86, because the back end insists that `IPAD' be
 125      aligned to a 4-byte boundary, but the processor has no such
 126      requirement (though it's good for performance).
 127
 128      It is possible that this is not a real bug, and could be considered
 129      a performance feature, but it might be important to provide the
 130      ability to Fortran code to specify minimum padding for aggregate
 131      areas such as common blocks--and, certainly, there is the
 132      potential, with the current setup, for interface differences in
 133      the way such areas are laid out between `g77' and other compilers.
 134
 135    * Some crashes occur when compiling under Solaris on x86 machines.
 136
 137      Nothing has been heard about any such problems for some time, so
 138      this is considering a closed item as of 0.5.20.  Please submit any
 139      bug reports pertinent to `g77''s support for Solaris/x86 systems.
 140
 141    * RS/6000 support is not complete as of the gcc 2.6.3 back end.  The
 142      2.7.0 back end appears to fix this problem, or at least mitigate
 143      it significantly, but there is at least one known problem that is
 144      likely to be a code-generation bug in `gcc-2.7.0' plus
 145      `g77-0.5.16'.  This problem shows up only when compiling the
 146      Fortran program with `-O'.
 147
 148      Nothing has been heard about any RS/6000 problems for some time,
 149      so this is considering a closed item as of 0.5.20.  Please submit
 150      any bug reports pertinent to `g77''s support for RS/6000 systems.
 151
 152    * SGI support is known to be a bit buggy.  The known problem shows
 153      up only when compiling the Fortran program with `-O'.
 154
 155      It is possible these problems have all been fixed in 0.5.20 by
 156      emulating complex arithmetic in the front end.  Please submit any
 157      bug reports pertinent to `g77''s support for SGI systems.
 158
 159    * `g77' doesn't work perfectly on 64-bit configurations such as the
 160      Alpha.  This problem is expected to be largely resolved as of
 161      version 0.5.20, and further addressed by 0.5.21.  Version 0.6
 162      should solve most or all related problems (such as 64-bit machines
 163      other than Digital Semiconductor ("DEC") Alphas).
 164
 165      One known bug that causes a compile-time crash occurs when
 166      compiling code such as the following with optimization:
 167
 168           SUBROUTINE CRASH (TEMP)
 169           INTEGER*2 HALF(2)
 170           REAL TEMP
 171           HALF(1) = NINT (TEMP)
 172           END
 173
 174      It is expected that a future version of `g77' will have a fix for
 175      this problem, almost certainly by the time `g77' supports the
 176      forthcoming version 2.8.0 of `gcc'.
 177
 178    * Maintainers of gcc report that the back end definitely has "broken"
 179      support for `COMPLEX' types.  Based on their input, it seems many
 180      of the problems affect only the more-general facilities for gcc's
 181      `__complex__' type, such as `__complex__ int' (where the real and
 182      imaginary parts are integers) that GNU Fortran does not use.
 183
 184      Version 0.5.20 of `g77' works around this problem by not using the
 185      back end's support for `COMPLEX'.  The new option
 186      `-fno-emulate-complex' avoids the work-around, reverting to using
 187      the same "broken" mechanism as that used by versions of `g77'
 188      prior to 0.5.20.
 189
 190    * There seem to be some problems with passing constants, and perhaps
 191      general expressions (other than simple variables/arrays), to
 192      procedures when compiling on some systems (such as i386) with
 193      `-fPIC', as in when compiling for ELF targets.  The symptom is
 194      that the assembler complains about invalid opcodes.  More
 195      investigation is needed, but the problem is almost certainly in
 196      the gcc back end, and it apparently occurs only when compiling
 197      sufficiently complicated functions *without* the `-O' option.
 198