[Bug lto/65536] LTO line number information garbled

["hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-25
     Ever confirmed|0                           |1

--- Comment #36 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Manuel,
I returned back looking for reason lines are going out wrong when we get short
on locators.  I do not understand the following code:

  if (line_delta < 0
      || (line_delta > 10
          && line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > 1000)
      || (max_column_hint >= (1U << ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)))
      || (max_column_hint <= 80
          && ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) >= 10)
      || (highest > 0x60000000
          && (set->max_column_hint || highest > 0x70000000)))
    add_map = true;
  else
    max_column_hint = set->max_column_hint;

here we seem to decide about adding new map and we always do that when we are
running tight on locators...

then
  if (add_map)
    {
      int column_bits;
      if (max_column_hint > 100000 || highest > 0x60000000)
        {
          /* If the column number is ridiculous or we've allocated a huge
             number of source_locations, give up on column numbers. */
          max_column_hint = 0;
          if (highest > 0x70000000)
            return 0;

I will add abort to highest and check if we reach it for chromium.
We probably can starting slowing down and allocating new linemap for every new
line, not try the heuristics with 1000 above.
However...

          column_bits = 0;
        }
      else
        {
          column_bits = 7;
          while (max_column_hint >= (1U << column_bits))
            column_bits++;
          max_column_hint = 1U << column_bits;
        }
      /* Allocate the new line_map.  However, if the current map only has a
         single line we can sometimes just increase its column_bits instead. */
      if (line_delta < 0
          || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
          || SOURCE_COLUMN (map, highest) >= (1U << column_bits))
        map = (struct line_map *) linemap_add (set, LC_RENAME,
                                               ORDINARY_MAP_IN_SYSTEM_HEADER_P
                                               (map),
                                               ORDINARY_MAP_FILE_NAME (map),
                                               to_line);
      ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) = column_bits;
      r = (MAP_START_LOCATION (map)
           + ((to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
              << column_bits));

Here we seem to sometimes affect ORDINARY_MAP_NUMBER_OF_COLUMN_BITS of an
existing line map.  How that can work?  We already have locators that do
depends on the previous COLUMN_BITS value.
I would expect the ORDINARY_MPA_NUMBER_OF_COLUMN_BITS set to be part of the
conditional and the computation bellow use map's column_bits.
Also I think the conditoinal guarding creation may want to check how far r will
be bumped and force creation when we are running short of locators.

Honza