This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/65536] LTO line number information garbled


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]