342 lines
12 KiB
Plaintext
342 lines
12 KiB
Plaintext
@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
|