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
