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 ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 26 Mar 2015 00:19:28 +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 #44 from Jan Hubicka <hubicka at ucw dot cz> ---
>
> Ah, ok, it seems to work now. It just takes ages to print the lto1 line and it
> get printed way after the lto1 process is running already.
Yep, really anoying property that the stderr output is all buffered and output
only at once. Something to do with libiberty.
> > There is a path in linemap_add_line that does not increase locator, but it
> > is bit bogus. I am playing with patch to improve this.
>
> Which path?
>
> What for sure happens is that when linemap_start_line starts returning 0, then
> linemap_postion_for_column will always return the same location until
> linemap_add is called directly (because of a change of file in the case of
> LTO).
Ah yes, you are right, it returns 0. I think this is bug too.
We probably want to return last map or have a dedicated location for out
of range?
GCC uses:
#define DECL_IS_BUILTIN(DECL)
(LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION)
so I think returning 0 will make us to believe that declaration with out of
range location is builtin that will definitly lead to wrong code.
Honza