+++ /dev/null
-_Note:_ This file is automatically generated from the files
-`bugs0.texi' and `bugs.texi'. `BUGS' is _not_ a source file, although
-it is normally included within source distributions.
-
- This file lists known bugs in the GCC-3.2.3 version of the GNU
-Fortran compiler. Copyright (C)
-1995,1996,1997,1998,1999,2000,2001,2002 Free Software Foundation, Inc.
-You may copy, distribute, and modify it freely as long as you preserve
-this copyright notice and permission notice.
-
-Known Bugs In GNU Fortran
-*************************
-
- This section identifies bugs that `g77' _users_ might run into in
-the GCC-3.2.3 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
-`gcc/gcc/f/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 `gcc') is available
-via `http://www.gnu.org/software/gcc/onlinedocs/g77/Trouble.html'.
-Follow the "Known Bugs" link.
-
- The following information was last updated on 2002-02-01:
-
- * `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.
-
- * `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.
-
- 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.
-
- * 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.
-
- * `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.
-
projects / msp430-gcc.git / blobdiff