[Bug lto/65536] LTO line number information garbled

["marxin at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Martin LiÅka <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #4 from Martin LiÅka <marxin at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #0)
> As shown in https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html
> warnings seems to come out wrong with large programs.  I did not manage to
> reproduce it with small testcase.  Columns tends to be 0 and line numbers
> (somewhat) off usually pointing to the begging of type definition instead of
> the field in question but sometimes they just point in further distance.
> 
> This reproduce both on Fireofx and Chromium
> 
> The problem goes away with:
> 
> Index: lto-streamer-in.c
> ===================================================================
> --- lto-streamer-in.c   (revision 221582)
> +++ lto-streamer-in.c   (working copy)
> @@ -200,7 +200,7 @@ lto_input_location (struct bitpack_d *bp
>    if (column_change)
>      current_col = bp_unpack_var_len_unsigned (bp);
>  
> -  if (file_change)
> +  if (file_change || 1)
>      {
>        if (prev_file)
>         linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> 
> (which also quite significantly increases memory use).  The warnings seems
> to be right on beggining and gets worse at end, so I suspect it is some kind
> of overflow in libcpp.
> 
> The problem stays with:
> 
> Index: lto-streamer-in.c
> ===================================================================
> --- lto-streamer-in.c   (revision 221582)
> +++ lto-streamer-in.c   (working copy)
> @@ -207,7 +207,7 @@ lto_input_location (struct bitpack_d *bp
>  
>        linemap_add (line_table, LC_ENTER, false, current_file, current_line);
>      }
> -  else if (line_change)
> +  else if (line_change || 1)
>      linemap_line_start (line_table, current_line, current_col);
>  
>    return linemap_position_for_column (line_table, current_col);
> 
> One obvious thing is that linemap_line_start takes argument 3 to be max
> column hint, but we pass current_col that is not cool.
> 
> I see that libcpp seems to drop the column info after some threshold (that
> is clearly too small for LTO) but why the line numbers are off?

Unfortunately, following patch causes SEGFAULT:
Program received signal SIGSEGV, Segmentation fault.
memset () at ../sysdeps/x86_64/memset.S:80
80    ../sysdeps/x86_64/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../sysdeps/x86_64/memset.S:80
#1  0x0000000000ed8ebd in new_linemap (set=set@entry=0x7ffff7fee000,
reason=reason@entry=LC_ENTER) at ../../libcpp/line-map.c:265
#2  0x0000000000ed9288 in linemap_add (set=0x7ffff7fee000,
reason=reason@entry=LC_ENTER, sysp=sysp@entry=0, 
    to_file=0x12d245f0 "../../ui/views/controls/image_view.h", to_line=92) at
../../libcpp/line-map.c:314
#3  0x000000000080d439 in lto_input_location (bp=<optimized out>,
data_in=<optimized out>) at ../../gcc/lto-streamer-in.c:208
#4  0x0000000000a8ba06 in streamer_read_tree_bitfields
(ib=ib@entry=0x7fffffffd620, data_in=data_in@entry=0xc3281b0, 
    expr=expr@entry=0x7fff163d05e8) at ../../gcc/tree-streamer-in.c:506
#5  0x000000000080a572 in lto_read_tree_1 (ib=0x7fffffffd620,
data_in=0xc3281b0, expr=0x7fff163d05e8)
    at ../../gcc/lto-streamer-in.c:1193
#6  0x000000000080a8e5 in lto_read_tree (hash=399977849, tag=<optimized out>,
data_in=0xc3281b0, ib=0x7fffffffd620)
    at ../../gcc/lto-streamer-in.c:1230
#7  lto_input_tree_1 (ib=0x7fffffffd620, data_in=0xc3281b0, tag=<optimized
out>, hash=399977849) at ../../gcc/lto-streamer-in.c:1349
#8  0x000000000080abe2 in lto_input_scc (ib=ib@entry=0x7fffffffd620,
data_in=data_in@entry=0xc3281b0, len=len@entry=0x7fffffffd618, 
    entry_len=entry_len@entry=0x7fffffffd61c) at
../../gcc/lto-streamer-in.c:1254
#9  0x00000000005b39b7 in lto_read_decls
(decl_data=decl_data@entry=0x7fff1b99f000, data=data@entry=0x151de970,
resolutions=..., 
    resolutions@entry=...) at ../../gcc/lto/lto.c:1902
#10 0x00000000005b52ac in lto_file_finalize (file=<optimized out>,
file_data=0x7fff1b99f000) at ../../gcc/lto/lto.c:2236
#11 lto_create_files_from_ids (count=<synthetic pointer>,
file_data=0x7fff1b99f000, file=0xbf4b5f0) at ../../gcc/lto/lto.c:2246
#12 lto_file_read (count=<synthetic pointer>, resolution_file=<optimized out>,
file=<optimized out>) at ../../gcc/lto/lto.c:2287
#13 read_cgraph_and_symbols (fnames=<optimized out>, nfiles=<optimized out>) at
../../gcc/lto/lto.c:2992
#14 lto_main () at ../../gcc/lto/lto.c:3462
#15 0x0000000000903592 in compile_file () at ../../gcc/toplev.c:594
#16 0x000000000058f271 in do_compile () at ../../gcc/toplev.c:2076
#17 toplev::main (this=this@entry=0x7fffffffd7f0, argc=13846, argc@entry=34,
argv=0x192f9f0, argv@entry=0x7fffffffd8f8)
    at ../../gcc/toplev.c:2174
#18 0x000000000058fa6a in main (argc=34, argv=0x7fffffffd8f8) at
../../gcc/main.c:39

More precisely, I used patched compiler just for WPA phase, should also this
set-up work?

Martin