This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/65536] LTO line number information garbled
- From: "hubicka at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 24 Mar 2015 23:34:37 +0000
- Subject: [Bug lto/65536] LTO line number information garbled
- Auto-submitted: auto-generated
- References: <bug-65536-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #24 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Manuel, you may be right person to implement the streaming of linemaps then :)
I suppose we do care about inline stacks in longer term to get proper warnings.
We even may want to preserve macro expansion and all other info we have at
compile time.
In addition to that we ought to be able to tell what compilation unit the line
infromation originate from
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01876.html because same location
in different units may have (and often has) different context. Not for GCC 5
though.
I will still experiment with the idea of adding locations to linemaps only once
tree merging found the tree location new. On average we read every tree about
20 times for Firefox, so this ought to reduce the waste of linemap space quite
considerably perhaps pushing it to non-issue for GCC 5.
honza