path: root/gnu/usr.bin/gcc/f/bugs.texi

@c Copyright (C) 1995, 1996 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 1996-11-27

@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
@cindex -fugly option
@cindex options, -fugly
@item
When using @samp{-fugly}, @code{g77} assumes an extra
@samp{%VAL(0)} argument is to be passed to intrinsics
taking no arguments, such as @samp{IARGC()}, which in
turn reject such a call.
Although this has been worked around for 0.5.18 due
to changes in the handling of intrinsics,
@code{g77} needs to do the ugly-argument-appending trick
only for external-function invocation, as this would
probably be more consistent with compilers that default
to using that trick.

@item
Although @code{g77} generally supports @samp{SELECT CASE},
it doesn't do so for @samp{CHARACTER} types.
Worse, it just crashes with a barely servicable
diagnostic.
If the time can't be taken soon to finish implementing
this feature, at least a better way of diagnosing
the problem should be provided.

@item
To accept a lot of fine code, @code{g77} needs to
accept @samp{FORMAT} and @samp{ENTRY} before an
@samp{IMPLICIT NONE}.

@item
Some crashes occur when compiling under Solaris on x86
machines.

@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 @samp{CONTINUE}
statements as the terminal statement, using the @samp{END DO}
form instead, and so on.

@item
The @code{g77} command itself should more faithfully process
options the way the @code{gcc} command does.
For example, @code{gcc} accepts abbreviated forms of long options,
@code{g77} generally doesn't.

@item
Some confusion in diagnostics concerning failing @samp{INCLUDE}
statements from within @samp{INCLUDE}'d or @samp{#include}'d files.

@item
Some problems on RS/6000 regarding statement functions and/or
@samp{COMPLEX} arithmetic?

@cindex integer constants
@cindex constants, integer
@item
@code{g77} assumes that @samp{INTEGER} 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 @samp{INTEGER}
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 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 @samp{CHARACTER*1} and @samp{IPAD}
is @samp{INTEGER*4} 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's good for
performance).

It is possible that this is not a real bug, and could be considered
a performance feature, but it might be important to provide
the ability to Fortran code to specify minimum padding for
aggregate areas such as common blocks---and, certainly, there
is the potential, with the current setup, for interface differences
in the way such areas are laid out between @code{g77} and other
compilers.

@cindex RS/6000 support
@cindex support, RS/6000
@item
RS/6000 support is not complete as of the gcc 2.6.3 back end.
The 2.7.0 back end appears to fix this problem, or at least mitigate
it significantly, but there is at least one known problem that is
likely to be a code-generation bug in @file{gcc-2.7.0} plus
@file{g77-0.5.16}.
This problem shows up only when compiling the Fortran program with @samp{-O}.

@cindex SGI support
@cindex support, SGI
@item
SGI support is known to be a bit buggy.
The known problem shows up only when compiling the Fortran program with
@samp{-O}.

@cindex Alpha support
@cindex support, Alpha
@item
@code{g77} doesn't work on 64-bit configurations such as the Alpha.
This problem is expected to be largely resolved as of version 0.5.20,
and version 0.6 should solve most or all related problems (such as
64-bit machines other than DEC Alphas).

@cindex COMPLEX support
@cindex support, COMPLEX
@item
Maintainers of gcc report that the back end definitely has ``broken''
support for @samp{COMPLEX} types.
Based on their input, it seems many of
the problems affect only the more-general facilities for gcc's
@samp{__complex__} type, such as @samp{__complex__ int}
(where the real and imaginary parts are integers) that GNU
Fortran does not use.

Version 0.5.20 of @code{g77} is expected to work around this
problem by not using the back end's support for @samp{COMPLEX}.
This work has already been done, and is being tested by
developers.

@cindex ELF support
@cindex support, ELF
@cindex -fPIC option
@cindex options, -fPIC
@item
There seem to be some problems with passing constants, and perhaps
general expressions (other than simple variables/arrays), to procedures
when compiling on some systems (such as i386) with @samp{-fPIC}, as in
when compiling for ELF targets.
The symptom is that the assembler complains about invalid opcodes.
More investigation is needed, but the problem is almost certainly
in the gcc back end, and it apparently occurs only when
compiling sufficiently complicated functions @emph{without} the
@samp{-O} option.

This might be fixed in version 2.7.2 of @code{gcc}.
@end itemize