[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.) -cary ---------- Forwarded message ---------- From: ccoutant at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> Date: Mon, Jun 25, 2012 at 2:19 PM Subject: [Bug debug/53754] [4.8 Regression][lto] ICE in lhd_decl_printable_name, at langhooks.c:222 (with -g) To: ccout...@google.com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53754 Cary Coutant <ccoutant at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | --- Comment #4 from Cary Coutant <ccoutant at gcc dot gnu.org> 2012-06-25 21:19:17 UTC --- Created attachment 27705 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27705 Patch to fix ICE with -g -flto and anonymous namespace > 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 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? 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? -cary -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. On Mon, Jun 25, 2012 at 2:19 PM, ccoutant at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53754 > > Cary Coutant <ccoutant at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org > |gnu.org | > > --- Comment #4 from Cary Coutant <ccoutant at gcc dot gnu.org> 2012-06-25 > 21:19:17 UTC --- > Created attachment 27705 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27705 > Patch to fix ICE with -g -flto and anonymous namespace > > > 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 > 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? > > 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? > > -cary > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
