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.
