This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][C++] Fix dump-file corruption


On 10/9/05, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Guenther wrote:
>
> > Fixed by moving (swapping) a cached decls name to the position it would
> > have had if it had been freshly allocated.  This ensures that we can
> > reliably print strings with at least RING_SIZE decl names in them.
>
> But, not with more names than that.  It's a bug to hold on to the memory
> returned by cxx_printable_name; you have to either print or copy the
> returned value immediately.  So, I don't think the bug is in
> cxx_printable_name; it sounds like the bug is in whatever part of the
> compiler is trying to hold on to those values.

Well, do you want to re-define the langhooks semantic for 4.1?  How do
you propose to do stuff like (from ipa-inline.c)

          fprintf (dump_file,
                   "\nConsidering %s with %i insns to be inlined into %s\n"
                   " Estimated growth after inlined into all callees
is %+i insns.\n"
                   " Estimated badness is %i.\n",
                   cgraph_node_name (edge->callee),
                   edge->callee->global.insns,
                   cgraph_node_name (edge->caller),
                   cgraph_estimate_growth (edge->callee),
                   cgraph_edge_badness (edge));

with

const char *
cgraph_node_name (struct cgraph_node *node)
{
  return lang_hooks.decl_printable_name (node->decl, 2);
}

?  Do string copies and memory frees around each such print?  I preffer
the ringbuffer, which is really nice given we can exactly know the maximum
number of live strings.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]