https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-debug
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2018-09-25
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org
             Blocks|                            |87362
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot 
gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The following "works" for example (dropping most debuginfo for the inline
instance):

Index: tree-inline.c
===================================================================
--- tree-inline.c       (revision 264564)
+++ tree-inline.c       (working copy)
@@ -4525,7 +4525,8 @@ expand_call_inline (basic_block bb, gimp
      artificial decls inserted by the compiler itself.  We need to
      either link the inlined blocks into the caller block tree or
      not refer to them in any way to not break GC for locations.  */
-  if (gimple_block (stmt))
+  if (gimple_block (stmt)
+      || LOCATION_LOCUS (gimple_location (stmt)) == UNKNOWN_LOCATION)
     {
       id->block = make_node (BLOCK);
       BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
@@ -4591,7 +4592,7 @@ expand_call_inline (basic_block bb, gimp

   if (DECL_INITIAL (fn))
     {
-      if (gimple_block (stmt))
+      if (id->block)
        {
          tree *var;


likewise setting BLOCK_SOURCE_LOCATION to BUILTINS_LOCATION instead of
UNKNOWN_LOCATION (but that seems to be a hack, but we do get
DW_TAG_inlined_subroutine back that way).

So - any opinion / guidance?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
[Bug 87362] GCC produces with LTO debug info with which gdb is not happy about

Reply via email to