egcs-2.91.66 internal bug

[Barry Brachman]

Synopsis:
 egcs-2.91.66 19990314 (egcs-1.1.2 release) may not be maintaining
 current_function_name properly when compiling C++ code.  The variable may
 sometimes point to (apparently) random junk.

Environment:
 egcs-2.91.66 was compiled by GCC 2.8.1 on a Linux/Pentium II platform and
 it was configured for that target platform.

Description:
 I'm assuming that current_function_name should always point to something
 reasonable.  When compiling the attached C++ file, however, it appears that
 the memory that the variable is pointing to is freed and/or reallocated
 prematurely.
 
How-To-Repeat:
 I'm using gdb 4.17.
 Set some breakpoints in cc1plus and observe that current_function_name is
 sometimes not pointing to a printable ASCII string.  It seems to me that it
 should be pointing to a valid function name at these points.  I suggest a
 breakpoint in any of:
    config/i386/i386.c:ix86_prologue()
    config/i386/i386.c:function_epilogue()
    function.c:pop_function_context_from() after
        current_function_name = p->name;
 You may add a condition to the breakpoint: !isprint(current_function_name[0])
 Then:
    run -quiet < vpcc2.ii > /dev/null
 At a breakpoint, print the value of current_function_name.

Fix:
 I suspect the problem is in the maintenance of the print_ring cache in
 cp/tree.c:lang_printable_name(), but I'm not certain.  If you insert the
 following as the first line of that function, the bug disappears:
     return(xstrdup (lang_decl_name (decl, v)));
 Also, if you increase PRINT_RING_SIZE sufficiently from 4 (why 4??), the
 bug disappears.  I found a PRINT_RING_SIZE of 12 to be the minimum size needed
 to make the problem go away for this input file.

The input file that demonstrates the problem, vpcc2.ii, is attached in gzip
form.

Barry Brachman
Distributed Systems Software