| @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-07-15 |
| |
| @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 |
| 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 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. |
| This bug is in the gcc back end, |
| and it apparently occurs only when |
| compiling sufficiently complicated functions @emph{without} the |
| @samp{-O} option. |
| |
| Fixed in @code{egcs} version 1.1. |
| |
| @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 |