(g77.info.gz) Known Bugs

 
 Known Bugs In GNU Fortran
 =========================
 
    This section identifies bugs that `g77' *users* might run into in
 the GCC-2.95 version of `g77'.  This includes bugs that are actually in
 the `gcc' back end (GBE) or in `libf2c', because those sets of code are
 at least somewhat under the control of (and necessarily intertwined
 with) `g77', so it isn't worth separating them out.
 
    For information on bugs in *other* versions of `g77', see  News
 About GNU Fortran News.  There, lists of bugs fixed in various
 versions of `g77' can help determine what bugs existed in prior
 versions.
 
    An online, "live" version of this document (derived directly from
 the mainline, development version of `g77' within `egcs') is available
 via `http://www.gnu.org/software/gcc/onlinedocs/g77_bugs.html'.  Follow
 the "Known Bugs" link.
 
    For information on bugs that might afflict people who configure,
 port, build, and install `g77', see  Problems Installing.
 
    The following information was last updated on 1999-06-29:
 
    * `g77' fails to warn about use of a "live" iterative-DO variable as
      an implied-DO variable in a `WRITE' or `PRINT' statement (although
      it does warn about this in a `READ' statement).
 
    * Something about `g77''s straightforward handling of label
      references and definitions sometimes prevents the GBE from
      unrolling loops.  Until this is solved, try inserting or removing
      `CONTINUE' statements as the terminal statement, using the `END DO'
      form instead, and so on.
 
    * Some confusion in diagnostics concerning failing `INCLUDE'
      statements from within `INCLUDE''d or `#include''d files.
 
    * `g77' assumes that `INTEGER(KIND=1)' constants range from `-2**31'
      to `2**31-1' (the range for two's-complement 32-bit values),
      instead of determining their range from the actual range of the
      type for the configuration (and, someday, for the constant).
 
      Further, it generally doesn't implement the handling of constants
      very well in that it makes assumptions about the configuration
      that it no longer makes regarding variables (types).
 
      Included with this item is the fact that `g77' doesn't recognize
      that, on IEEE-754/854-compliant systems, `0./0.' should produce a
      NaN and no warning instead of the value `0.' and a warning.  This
      is to be fixed in version 0.6, when `g77' will use the `gcc' back
      end's constant-handling mechanisms to replace its own.
 
    * `g77' uses way too much memory and CPU time to process large
      aggregate areas having any initialized elements.
 
      For example, `REAL A(1000000)' followed by `DATA A(1)/1/' takes up
      way too much time and space, including the size of the generated
      assembler file.  This is to be mitigated somewhat in version 0.6.
 
      Version 0.5.18 improves cases like this--specifically, cases of
      *sparse* initialization that leave large, contiguous areas
      uninitialized--significantly.  However, even with the
      improvements, these cases still require too much memory and CPU
      time.
 
      (Version 0.5.18 also improves cases where the initial values are
      zero to a much greater degree, so if the above example ends with
      `DATA A(1)/0/', the compile-time performance will be about as good
      as it will ever get, aside from unrelated improvements to the
      compiler.)
 
      Note that `g77' does display a warning message to notify the user
      before the compiler appears to hang.   Initialization of
      Large Aggregate Areas Large Initialization, for information on
      how to change the point at which `g77' decides to issue this
      warning.
 
    * `g77' doesn't emit variable and array members of common blocks for
      use with a debugger (the `-g' command-line option).  The code is
      present to do this, but doesn't work with at least one debug
      format--perhaps it works with others.  And it turns out there's a
      similar bug for local equivalence areas, so that has been disabled
      as well.
 
      As of Version 0.5.19, a temporary kludge solution is provided
      whereby some rudimentary information on a member is written as a
      string that is the member's value as a character string.
 
       Options for Code Generation Conventions Code Gen Options,
      for information on the `-fdebug-kludge' option.
 
    * When debugging, after starting up the debugger but before being
      able to see the source code for the main program unit, the user
      must currently set a breakpoint at `MAIN__' (or `MAIN___' or
      `MAIN_' if `MAIN__' doesn't exist) and run the program until it
      hits the breakpoint.  At that point, the main program unit is
      activated and about to execute its first executable statement, but
      that's the state in which the debugger should start up, as is the
      case for languages like C.
 
    * Debugging `g77'-compiled code using debuggers other than `gdb' is
      likely not to work.
 
      Getting `g77' and `gdb' to work together is a known
      problem--getting `g77' to work properly with other debuggers, for
      which source code often is unavailable to `g77' developers, seems
      like a much larger, unknown problem, and is a lower priority than
      making `g77' and `gdb' work together properly.
 
      On the other hand, information about problems other debuggers have
      with `g77' output might make it easier to properly fix `g77', and
      perhaps even improve `gdb', so it is definitely welcome.  Such
      information might even lead to all relevant products working
      together properly sooner.
 
    * `g77' doesn't work perfectly on 64-bit configurations such as the
      Digital Semiconductor ("DEC") Alpha.
 
      This problem is largely resolved as of version 0.5.23.  Version
      0.6 should solve most or all remaining problems (such as
      cross-compiling involving 64-bit machines).
 
    * `g77' currently inserts needless padding for things like `COMMON
      A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER(KIND=1)'
      on machines like x86, because the back end insists that `IPAD' be
      aligned to a 4-byte boundary, but the processor has no such
      requirement (though it is usually good for performance).
 
      The `gcc' back end needs to provide a wider array of
      specifications of alignment requirements and preferences for
      targets, and front ends like `g77' should take advantage of this
      when it becomes available.
 
    * The `libf2c' routines that perform some run-time arithmetic on
      `COMPLEX' operands were modified circa version 0.5.20 of `g77' to
      work properly even in the presence of aliased operands.
 
      While the `g77' and `netlib' versions of `libf2c' differ on how
      this is accomplished, the main differences are that we believe the
      `g77' version works properly even in the presence of *partially*
      aliased operands.
 
      However, these modifications have reduced performance on targets
      such as x86, due to the extra copies of operands involved.
Info Catalog
(g77.info.gz) But-bugs
(g77.info.gz) Trouble
(g77.info.gz) Missing Features
automatically generated byinfo2html