[Bug debug/91231] ICE in dwarf2out_inline_entry, at dwarf2out.c:27642

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Jul 23 08:53:00 GMT 2019


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |dmalcolm at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the location of the NOTE_INSN_INLINE_ENTRY BLOCK is zero.

# DEBUG INLINE_ENTRY __conv_op 

and the BLOCKs location is streamed as '2', when the location cache is applied
it becomes zero here:

      if (current_file == loc.file && current_line == loc.line
          && current_col == loc.col)
        *loc.loc = current_loc;
      else
        current_loc = *loc.loc = linemap_position_for_column (line_table,
                                                              loc.col);

line changes.  Then linemap_position_for_column returns zero, current_loc
is 1879048191.

(gdb) p set->max_column_hint 
$43 = 0

still we're running into

          /* Otherwise, attempt to start a new line that can hold TO_COLUMN,
             with some space to spare.  This may or may not lead to a new
             linemap being created.  */
          line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP (set);
          r = linemap_line_start (set, SOURCE_LINE (map, r), to_column + 50);

and in linemap_line_start end up with add_map = true because
effective_column_bits is zero.

That is, the ultimative issue is that we run out of linemap space
(for no good reason in this case) which leads to some locations becoming
zero which we do not expect.

We can fixup at GIMPLE stmt stream-in time and drop the debug stmts which
make no sense anymore due to this and first and foremost fix the above
bug by not attempting to allocate space for 50 columns if max_column_hint
is zero and the actual column is zero as well.  Hmm, I guess it isn't
a global hint and LTO is really special by dropping column info...  Maybe
we shouldn't call linemap_position_for_column at all...

Anyway.  The following fixes the issue (yes, we do stream inline-entry
markers with NULL block):

Index: gcc/lto-streamer-in.c
===================================================================
--- gcc/lto-streamer-in.c       (revision 273718)
+++ gcc/lto-streamer-in.c       (working copy)
@@ -1140,6 +1140,14 @@ input_function (tree fn_decl, struct dat
                      ? !MAY_HAVE_DEBUG_MARKER_STMTS
                      : !MAY_HAVE_DEBUG_BIND_STMTS))
                remove = true;
+             /* In case the linemap overflows locations can be dropped
+                to zero.  Thus do not keep nonsensical inline entry markers
+                we'd later ICE on.  */
+             tree block;
+             if (gimple_debug_inline_entry_p (stmt)
+                 && (block = gimple_block (stmt))
+                 && !inlined_function_outer_scope_p (block))
+               remove = true;
              if (is_gimple_call (stmt)
                  && gimple_call_internal_p (stmt))
                {

As for the linemap issue we might be able to optimize the + 50 for LTO
somehow either by a new global parameter we set or by looking at past
column uses [of the same file]?


More information about the Gcc-bugs mailing list