@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 1999-03-13

@ifset BUGSONLY
@set which-g77 @code{egcs}-1.1.2
@end ifset

@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 in the @value{which-g77} version
of @code{g77}.
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.

@ifset last-up-date
For information on bugs in @emph{other} versions of @code{g77},
@ref{News,,News About GNU Fortran}.
@end ifset

@ifset BUGSONLY
For information on bugs in @emph{other} versions of @code{g77},
see @file{egcs/gcc/f/NEWS}.
@end ifset

An online, ``live'' version of this document
(derived directly from the up-to-date mainline version
of @code{g77} within @code{egcs})
is available at
@uref{http://egcs.cygnus.com/onlinedocs/g77_bugs.html}.

@ifset last-up-date
For information on bugs that might afflict people who
configure, port, build, and install @code{g77},
@ref{Problems Installing}.
@end ifset

@ifset BUGSONLY
For information on bugs that might afflict people who
configure, port, build, and install @code{g77},
see ``Problems Installing'' in @file{egcs/gcc/f/INSTALL}.
@end ifset

@itemize @bullet
@item
@code{g77} generates bad code for assignments,
or other conversions,
of @code{REAL} or @code{COMPLEX} constant expressions
to type @code{INTEGER(KIND=2)}
(often referred to as @code{INTEGER*8}).

For example, @samp{INTEGER*8 J; J = 4E10} is miscompiled
on some systems---the wrong value is stored in @var{J}.

@item
The @code{IDate} Intrinsic (VXT)
fails to return the year in the documented, non-Y2K-compliant range
of 0--99,
instead returning 100 for the year 2000.

@c Fixed in @code{egcs} 1.2.

@item
Year 2000 (Y2K) compliance information
is missing from the documentation.

@c Fixed in @code{egcs} 1.2.

@item
@code{g77} crashes when compiling
I/O statements using keywords that define @code{INTEGER} values,
such as @samp{IOSTAT=@var{j}},
where @var{j} is other than default @code{INTEGER}
(such as @code{INTEGER*2}).

@c Fixed in @code{egcs} 1.2.

@item
The @samp{-ax} option is not obeyed when compiling Fortran programs.
(It is not passed to the @file{f771} driver.)

@c Fixed in @code{egcs} 1.2.

@item
@code{g77} fails to warn about a reference to a function
when the corresponding @emph{subsequent} function program unit
disagrees with the reference concerning the type of the function.

@c Fixed in @code{egcs} 1.2.

@item
@c Tim Prince discovered this.
Automatic arrays possibly 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
@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
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.
@ifset last-up-date
@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.
@end ifset

@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.

@ifset last-up-date
@xref{Code Gen Options,,Options for Code Generation Conventions},
for information on the @samp{-fdebug-kludge} option.
@end ifset

@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 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 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