[Bug lto/65536] LTO line number information garbled

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

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

--- Comment #5 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> The main issue with LTO is that it re-creates a combined linemap but in (most
> of the time) quite awkward ordering (simply registering random-ordered
> file:line:column entries by switching files/lines "appropriately").
> 
> I've argued that it would be better to stream those file:line:columns
> separately so we can "sort" them before handing them over to libcpp for
> linemap re-creation.

If the lines or columns are out of order, then all bets are off. Line-map
locations have to be allocated incrementally. If you switch between files a
lot, then you are wasting a lot of memory unnecessarily, since switching
requires creating a new line-map.

How difficult would be to track on which file you are and simply have a
line_table per file and switch the current line_table appropriately?

> So currently we do, for each "file:line:column" location we stream in:
> 
>   if (file_change)
>     {
>       if (prev_file)
>         linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> 
>       linemap_add (line_table, LC_ENTER, false, current_file, current_line);
>     }
>   else if (line_change)
>     linemap_line_start (line_table, current_line, current_col);
> 
>   return linemap_position_for_column (line_table, current_col);
> 
> which of course puts a heavy load on the linemap encoding...

According to line-map.h:

/* Reason for creating a new line map with linemap_add.  LC_ENTER is
   when including a new file, e.g. a #include directive in C.
   LC_LEAVE is when reaching a file's end.  LC_RENAME is when a file
   name or line number changes for neither of the above reasons
   (e.g. a #line directive in C);

Thus I'm not sure the above is really correct. If a single line_table is
desirable, it probably should use LC_RENAME for different main files (as if
they were concatenated and using #line). LC_LEAVE/LC_ENTER only makes sense for
included files, which I presume are slightly different than concatenated files.

line-map.c has code to make some erroneous cases "work": I think they should be
replaced by linemap_assert_fails(), such that they trigger an assert when
checking but they try to recover gracefully otherwise.

How are the original locations stored on disk?

> But it should definitely work (not sure what it does on line or file
> "overflow").

I'm not sure lines or files can really overflow, but location_t can, and the
only "fix" is that column numbers get disabled (highest location > 0x60000000),
but there is nothing stopping it from really overflowing after that.