This is the mail archive of the gcc-bugs@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]

[Bug c/66415] [6 Regression] ice in location_column_from_byte_offset


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

--- Comment #6 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #5)
> Oops, the patch does not fixed the reduced case, so something else is needed
> as well :(.

It seems this is triggering:

  if (map != LINEMAPS_LAST_ORDINARY_MAP (set))
=>  if (linemap_assert_fails (loc + offset < MAP_START_LOCATION (&map[1])))
      return loc;

because we have:

(gdb) p loc
$10 = 441
(gdb) p loc + offset
$11 = 460
(gdb) p MAP_START_LOCATION(&map[1])
$12 = 442
(gdb) p expand_location(MAP_START_LOCATION(&map[0]))
$14 = {file = 0x7fffffffe7ea "/home/manuel/test.c", line = 1, column = 0, data
= 0x0, sysp = false}
(gdb) p expand_location(MAP_START_LOCATION(&map[1]))
$13 = {file = 0x7fffffffe7ea "/home/manuel/test.c", line = 4, column = 0, data
= 0x0, sysp = false}

I'm not sure how it happens that 441 is in map[0] and not in map[1]. The ideal
fix would be that we detect this case and then use map[1] instead of map[0]
before calling linemap_position_for_line_and_column. We probably need to check
every subsequent map until it fits.

A simple fix is to remove the call to linemap_assert_fails and simply return
loc (that is, give up on computing a precise column location). In that case,
please add a FIXME. I may look at this if/when I have some free time (hopefully
before GCC 6 is released).

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