initial commit

1 files changed, 320 insertions, 0 deletions

diff --git a/gcc/f/bugs.texi b/gcc/f/bugs.texi
new file mode 100755
index 0000000..b591cfc
--- /dev/null
+++ b/gcc/f/bugs.texi
@@ -0,0 +1,320 @@
+@c Copyright (C) 1995-1998 Free Software Foundation, Inc.
+@c This is part of the G77 manual.
+@c For copying conditions, see the file g77.texi.
+
+@c The text of this file appears in the file BUGS
+@c in the G77 distribution, as well as in the G77 manual.
+
+@c 1998-09-01
+
+@ifclear BUGSONLY
+@node Actual Bugs
+@section Actual Bugs We Haven't Fixed Yet
+@end ifclear
+
+This section identifies bugs that @code{g77} @emph{users}
+might run into.
+This includes bugs that are actually in the @code{gcc}
+back end (GBE) or in @code{libf2c}, because those
+sets of code are at least somewhat under the control
+of (and necessarily intertwined with) @code{g77}, so it
+isn't worth separating them out.
+
+For information on bugs that might afflict people who
+configure, port, build, and install @code{g77},
+@ref{Problems Installing}.
+
+@itemize @bullet
+@item
+@code{g77} sometimes crashes when compiling code
+containing the construct @samp{CMPLX(0.)} or similar.
+This is a @code{gcc} back-end bug.
+It can be worked around using @samp{-fno-emulate-complex},
+though that might trigger other, older bugs.
+Compiling without optimization is another work-around.
+
+Fixed in @code{egcs} 1.1.
+
+@item
+@c Tim Prince discovered this.
+Automatic arrays aren't working on HP-UX systems,
+at least in HP-UX version 10.20.
+Writing into them apparently causes over-writing
+of statically declared data in the main program.
+This probably means the arrays themselves are being under-allocated,
+or pointers to them being improperly handled,
+e.g. not passed to other procedures as they should be.
+
+@item
+@c Toon Moene discovered these.
+Some Fortran code has been found to be miscompiled
+by @code{g77} built on @code{gcc} version 2.8.1
+on m68k-next-nextstep3 configurations
+when using the @samp{-O2} option.
+Even a C function is known to miscompile
+on that configuration
+when using the @samp{-O2 -funroll-loops} options.
+
+Fixed in @code{egcs}.
+
+@cindex DNRM2
+@cindex stack, 387 coprocessor
+@cindex ix86
+@cindex -O2
+@item
+A code-generation bug afflicts
+Intel x86 targets when @samp{-O2} is specified
+compiling, for example, an old version of
+the @samp{DNRM2} routine.
+The x87 coprocessor stack is being
+mismanaged in cases where assigned @code{GOTO}
+and @code{ASSIGN} are involved.
+
+Fixed in @code{egcs} version 1.1.
+
+@item
+@code{g77} fails to warn about
+use of a ``live'' iterative-DO variable
+as an implied-DO variable
+in a @samp{WRITE} or @samp{PRINT} statement
+(although it does warn about this in a @samp{READ} statement).
+
+@item
+A compiler crash, or apparently infinite run time,
+can result when compiling complicated expressions
+involving @code{COMPLEX} arithmetic
+(especially multiplication).
+
+Fixed in @code{egcs} version 1.1.
+
+@item
+Something about @code{g77}'s straightforward handling of
+label references and definitions sometimes prevents the GBE
+from unrolling loops.
+Until this is solved, try inserting or removing @code{CONTINUE}
+statements as the terminal statement, using the @code{END DO}
+form instead, and so on.
+
+@item
+Some confusion in diagnostics concerning failing @code{INCLUDE}
+statements from within @code{INCLUDE}'d or @code{#include}'d files.
+
+@cindex integer constants
+@cindex constants, integer
+@item
+@code{g77} assumes that @code{INTEGER(KIND=1)} constants range
+from @samp{-2**31} to @samp{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 @code{g77} doesn't recognize
+that, on IEEE-754/854-compliant systems, @samp{0./0.} should produce a NaN
+and no warning instead of the value @samp{0.} and a warning.
+This is to be fixed in version 0.6, when @code{g77} will use the
+@code{gcc} back end's constant-handling mechanisms to replace its own.
+
+@cindex compiler speed
+@cindex speed, of compiler
+@cindex compiler memory usage
+@cindex memory usage, of compiler
+@cindex large aggregate areas
+@cindex initialization
+@cindex DATA statement
+@cindex statements, DATA
+@item
+@code{g77} uses way too much memory and CPU time to process large aggregate
+areas having any initialized elements.
+
+For example, @samp{REAL A(1000000)} followed by @samp{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 @emph{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 @samp{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 @code{g77} does display a warning message to
+notify the user before the compiler appears to hang.
+@xref{Large Initialization,,Initialization of Large Aggregate Areas},
+for information on how to change the point at which
+@code{g77} decides to issue this warning.
+
+@cindex debugging
+@cindex common blocks
+@cindex equivalence areas
+@cindex local equivalence areas
+@item
+@code{g77} doesn't emit variable and array members of common blocks for use
+with a debugger (the @samp{-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.
+
+@xref{Code Gen Options,,Options for Code Generation Conventions},
+for information on the @samp{-fdebug-kludge} option.
+
+@cindex code, displaying main source
+@cindex displaying main source code
+@cindex debugging main source code
+@cindex printing main source
+@item
+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 @samp{MAIN__} (or @samp{MAIN___} or @samp{MAIN_} if
+@samp{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.
+
+@cindex debugger
+@item
+Debugging @code{g77}-compiled code using debuggers other than
+@code{gdb} is likely not to work.
+
+Getting @code{g77} and @code{gdb} to work together is a known
+problem---getting @code{g77} to work properly with other
+debuggers, for which source code often is unavailable to @code{g77}
+developers, seems like a much larger, unknown problem,
+and is a lower priority than making @code{g77} and @code{gdb}
+work together properly.
+
+On the other hand, information about problems other debuggers
+have with @code{g77} output might make it easier to properly
+fix @code{g77}, and perhaps even improve @code{gdb}, so it
+is definitely welcome.
+Such information might even lead to all relevant products
+working together properly sooner.
+
+@cindex Alpha, support
+@cindex support, Alpha
+@item
+@code{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).
+
+@cindex COMPLEX support
+@cindex support, COMPLEX
+@item
+Maintainers of @code{gcc} report that the back end definitely has ``broken''
+support for @code{COMPLEX} types.
+Based on their input, it seems many of
+the problems affect only the more-general facilities for gcc's
+@code{__complex__} type, such as @code{__complex__ int}
+(where the real and imaginary parts are integers) that GNU
+Fortran does not use.
+
+Version 0.5.20 of @code{g77} works around this
+problem by not using the back end's support for @code{COMPLEX}.
+The new option @samp{-fno-emulate-complex} avoids the work-around,
+reverting to using the same ``broken'' mechanism as that used
+by versions of @code{g77} prior to 0.5.20.
+
+@cindex ELF support
+@cindex support, ELF
+@cindex -fPIC option
+@cindex options, -fPIC
+@item
+@code{g77} sometimes produces invalid assembler code
+when using the @samp{-fPIC} option (such as compiling for ELF targets)
+on the Intel x86 architecture target.
+The symptom is that the assembler complains about invalid opcodes.
+This bug is in the @code{gcc} back end.
+
+Fixed in @code{egcs} version 1.0.2.
+
+@cindex padding
+@cindex structures
+@cindex common blocks
+@cindex equivalence areas
+@item
+@code{g77} currently inserts needless padding for things like
+@samp{COMMON A,IPAD} where @samp{A} is @code{CHARACTER*1} and @samp{IPAD}
+is @code{INTEGER(KIND=1)} on machines like x86,
+because the back end insists that @samp{IPAD}
+be aligned to a 4-byte boundary,
+but the processor has no such requirement
+(though it is usually good for performance).
+
+The @code{gcc} back end needs to provide a wider array
+of specifications of alignment requirements and preferences for targets,
+and front ends like @code{g77} should take advantage of this
+when it becomes available.
+
+@cindex alignment
+@cindex double-precision performance
+@cindex -malign-double
+@item
+The x86 target's @samp{-malign-double} option
+no longer reliably aligns double-precision variables and arrays
+when they are placed in the stack frame.
+
+This can significantly reduce the performance of some applications,
+even on a run-to-run basis
+(that is, performance measurements can vary fairly widely
+depending on whether frequently used variables are properly aligned,
+and that can change from one program run to the next,
+even from one procedure call to the next).
+
+Versions 0.5.22 and earlier of @code{g77}
+included a patch to @code{gcc} that enabled this,
+but that patch has been deemed an improper (probably buggy) one
+for version 2.8 of @code{gcc} and for @code{egcs}.
+
+Note that version 1.1 of @code{egcs}
+aligns double-precision variables and arrays
+when they are in static storage
+even if @samp{-malign-double} is not specified.
+
+There is ongoing investigation into
+how to make @samp{-malign-double} work properly,
+also into how to make it unnecessary to get
+all double-precision variables and arrays aligned
+when such alignment would not violate
+the relevant specifications for processor
+and inter-procedural interfaces.
+
+For a suite of programs to test double-precision alignment,
+see @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
+
+@cindex complex performance
+@cindex aliasing
+@item
+The @code{libf2c} routines that perform some run-time
+arithmetic on @code{COMPLEX} operands
+were modified circa version 0.5.20 of @code{g77}
+to work properly even in the presence of aliased operands.
+
+While the @code{g77} and @code{netlib} versions of @code{libf2c}
+differ on how this is accomplished,
+the main differences are that we believe
+the @code{g77} version works properly
+even in the presence of @emph{partially} aliased operands.
+
+However, these modifications have reduced performance
+on targets such as x86,
+due to the extra copies of operands involved.
+@end itemize