[Bug lto/65536] LTO line number information garbled

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #16 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
> 
> --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
> 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.

Yep, we discussed this few times.  One issue is when we sort them. 
We can keep track of location as they are streamed out (and directly assign
them new IDs in the awkward ordering as they come) and then produce the
separate linemap section that would be read at once by WPA, sorted and
fed into linemaps.

Sorting at compile time is bit tricky as we probably do not want to patch
existing pickled tree stream with the new locator IDs in the sorted sequence
and we do not really know what locations we will need ahead of time.

Other easier to implement idea for GCC 5 may be to simply collect locaiton
info and pointers to trees per SCC component andonly if it survived merging
feed it into linemap and in memory patch the new trees. This still should
save quite some memory given that most of trees read are discarded by merging
and may be quite easy to implement.

Martin, the ICE by my patch is caused by libcpp getting out of memory?