diff options
Diffstat (limited to 'gcc/f/bugs.texi')
| -rw-r--r-- | gcc/f/bugs.texi | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/gcc/f/bugs.texi b/gcc/f/bugs.texi new file mode 100644 index 00000000000..692e1b3a12f --- /dev/null +++ b/gcc/f/bugs.texi @@ -0,0 +1,287 @@ +@c Copyright (C) 1995-1997 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-06-24 + +@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 SIGNAL() intrinsic +@cindex intrinsics, SIGNAL() +@item +Work is needed on the @code{SIGNAL()} intrinsic to ensure +that pointers and integers are properly handled on all +targets, including 64-bit machines. + +@cindex -fugly-comma option +@cindex options, -fugly-comma +@item +When using @samp{-fugly-comma}, @code{g77} assumes an extra +@samp{%VAL(0)} argument is to be passed to intrinsics +taking no arguments, such as @code{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 +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. +(Probably improved, but not wholly fixed, in 0.5.21.) + +@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 @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 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'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. + +@item +Some crashes occur when compiling under Solaris on x86 +machines. + +Nothing has been heard about any such problems for some time, +so this is considering a closed item as of 0.5.20. +Please submit any bug reports pertinent to @code{g77}'s support +for Solaris/x86 systems. + +@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}. + +Nothing has been heard about any RS/6000 problems for some time, +so this is considering a closed item as of 0.5.20. +Please submit any bug reports pertinent to @code{g77}'s support +for RS/6000 systems. + +@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}. + +It is possible these problems have all been fixed in 0.5.20 by +emulating complex arithmetic in the front end. +Please submit any bug reports pertinent to @code{g77}'s support +for SGI systems. + +@cindex Alpha, support +@cindex support, Alpha +@item +@code{g77} doesn't work perfectly on 64-bit configurations such as the Alpha. +This problem is expected to be largely resolved as of version 0.5.20, +and further addressed by 0.5.21. +Version 0.6 should solve most or all related problems (such as +64-bit machines other than Digital Semiconductor (``DEC'') Alphas). + +One known bug that causes a compile-time crash occurs when compiling +code such as the following with optimization: + +@example +SUBROUTINE CRASH (TEMP) +INTEGER*2 HALF(2) +REAL TEMP +HALF(1) = NINT (TEMP) +END +@end example + +It is expected that a future version of @code{g77} will have a fix for this +problem, almost certainly by the time @code{g77} supports the forthcoming +version 2.8.0 of @code{gcc}. + +@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 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. +@end itemize + |