Re: Fwd: [Bug debug/53754] [4.8 Regression][lto] ICE in lhd_decl_printable_name, at langhooks.c:222 (with -g)

[Richard Guenther <rguenther at suse dot de>]

On Thu, 28 Jun 2012, Cary Coutant wrote:

> [resending in plain text. Sorry, gmail defaulted to HTML.]
> 
> Ping. I'm not looking for commit approval yet, just advice on how
> thorough we need to be to support -g and LTO together.
> 
> (What's the right way to send a patch to fix a PR? I'm not even sure
> whether you were cc'ed on my response.)

The right way to send a patch to fix a PR is to send it to gcc-patches ;)

> > You can't delay producing pubnames this way with LTO. ?Please fix.
> 
> The obvious problem is that we're calling langhooks.dwarf_name (in
> gen_namespace_die) for an anonymous namespace, even with the default
> -gno-pubnames. I can fix that by adding a check for want_pubnames just before
> the call to add_pubname_string, as in the patch below. But this is still going

That's sensible anyways - you avoid useless work.  So the patch is ok.
But still ...

> to ICE if you turn on -gpubnames with -lto. The only way I can think of to fix
> that is relax the assert in lhd_decl_printable_name, and just have it return an
> empty string in the DECL_NAMELESS case. That will not produce the right results
> for an anonmyous namespace, but without front-end langhooks available to us
> (and until we implement the lazy debug plan), how can we do better?

... produce the pubnames early.  I mean, each object you want to have its
pubname appear in .pubnames at dwarf2out.c time has to have the pubname
"created" by the frontend.  As far as I can quickly decipher the "pubname"
is what lang_hooks.dwarf_name () returns, right?  I'd say we have to
bite the bullet at some point (this point?) and add a pointer to
debug-format specific data to each tree node we eventually emit debug
information for (that is types and decls I presume, both at most those
that have the lang_specific pointer - in fact we might re-use that
pointer, initially hang off the debug-info ptr from lang_specific data
and at free-lang-data time re-link it as gimple-lang-specific).

> How much is expected to work today with LTO and -g? Aren't we still stuck with
> calling langhooks from dwarf2out.c back-end routines? I can understand that we
> don't want to ICE, but what guarantees do we make about debug info

Well, LTO and -g is expected to work as to not ICE and produce reasonable
debug information up to the point where we cannot create language specific
info late.  That's what you broke (the not-ICE part).  In practice LTO
with -g works quite well - you can even debug things.  It's of course not
perfect, but today only because of lang-hooks used in debug output and
because of the issue we have with early inline transforms (BLOCK trees
get slightly hosed there, there is a bug about this).

Richard.