From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-3smp i686) On RH7 with all updates installed, fisher and wolverine, there is an incompatibility of some kind between g77 and gdb. Apparently all local variables flagged with a SAVE statement (-> made static) or ALL VARIABLES in case the -fno-automatic option is used (which makes static all local variables) are invisible to the debugger. Every attempt to look at them results in No symbol "..." in current context. Everything worked nice under RH6.2. Of course debugging of programs is practically impossible, taking also into account that for historical reasons (all compilers were SAVing everything till a few years ago) many of them need to be compiled with -fno-automatic. I attach a small tar file with the same few line long code, compiled without -fno-automatic and ran into a crash (dobug1), compiled with -fno-automatic and crashed and slightly changed SAVing the variables and crashed. There is also a small c code to set on exception trapping. The latter two cases result in the wrong behaviour (gdb being unable to access the variables). The script dobugs does the whole job. Of course we hit the bug on much larger codes. Needless to say the problem is serious. Now that apparently most of the striking bugs of fortran support in RH7 are apparently solved, we are stopped again because of debugger issues. I selected the compiler as the faulty component but of course it could be the debugger as well or the linker in case it flags in some funny way those variables. I stress again that this is common to RH7, fisher and wolverine. A comment I cannot refrain from for the quality assurance guys: I followed all polemics on the RedHat lists about the compiler shipped with RH7 (and fisher and wolverine). I read the claims from the RedHat guys that is was thoroughly tested etc, among the others by compiling with it the whole distribution. However it is crystal clear that no test at all has been done with fortran (maybe compiling "hello world"), and that shipping a buggy and untested snapshot of the compiler for fortran users and developers (which are quite a large fraction of the scientific community) resulted in a major disaster. The compiler had major problems itself, unwise changes in the compiler/linker interaction resulted in further problems, the debugger does not work with the compiler, nice! After more than six months from its release RH7 and following are still poor alpha releases for what concern scientific calculations with fortran. Maybe a regular release of the compiler with all feedback from users it usually comes with would have been a wiser solution. I know there were good reasons to ship this snapshot instead, however RedHat should have taken all necessary steps to fix it in this case.Here at CERN most guys made the equation RH7=crap and indeed the Lab Computer Division discourages its use. I believe to be among the few ones who are trying to get usable (even though I do it on my test system only and all production machines on the group I am responsible for are still on 6.2), however it starts to be quite a discouraging task. Reproducible: Always Steps to Reproduce: 1.compile a fortran code with -fno-automatic or with SAVEd variables in a subroutine 2.run it in such a way to make it dump core 3.run gdb trying to access whichever SAVEd variable Actual Results: I cannot access any local variable in the debugger Expected Results: The debugger should be able to access local variables at it was able to do till 6.2
Created attachment 11123 [details] various files/scripts demonstrating the bug
Should be fixed by: 2000-09-22 Jason Merrill <jason> * dbxout.c (dbxout_symbol_name): Just use DECL_NAME for function-local names. which I've just added to my patch queue.
Fixed in gcc-2.96-77.1.