https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic, lto
Priority|P3 |P1
CC| |rguenth at gcc dot gnu.org
Component|lto |preprocessor
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
When looking at DECL_SOURCE_LOCATION of 'a' during compilation we get
#1 0x0000000001359e29 in streamer_write_tree_bitfields (ob=0x28ab160, expr=
<var_decl 0x7ffff7fefb40 a>)
at /space/rguenther/src/svn/trunk3/gcc/tree-streamer-out.c:434
434 stream_output_location (ob, &bp, DECL_SOURCE_LOCATION (expr));
(gdb) down
#0 lto_output_location (ob=0x28ab160, bp=0x7fffffffd750, loc=12480)
at /space/rguenther/src/svn/trunk3/gcc/lto-streamer-out.c:176
176 bp_pack_value (bp, ob->current_file != xloc.file, 1);
(gdb) p xloc
$2 = {file = 0x28f5680 "t.ii", line = 1048577, column = 5, data = 0x0,
sysp = false}
so the bogus info is there right from the start. Initialized through
Old value = 0
New value = 12480
make_node_stat (code=VAR_DECL)
at /space/rguenther/src/svn/trunk3/gcc/tree.c:1030
1029 DECL_SOURCE_LOCATION (t) = input_location;
(gdb) p expand_location (input_location)
$10 = {file = 0x28f5680 "t.ii", line = 1048577, column = 5, data = 0x0,
sysp = false}
there are other similarly bogus locations like
New value = 8224
fe_file_change (new_map=0x7ffff7fe1020)
at /space/rguenther/src/svn/trunk3/gcc/c-family/c-lex.c:228
228 (*debug_hooks->end_source_file) (LINEMAP_LINE (new_map));
(gdb) p expand_location (8224)
$13 = {file = 0x28f5680 "t.ii", line = 1048576, column = 0, data = 0x0,
sysp = false}
that's when c-lex.c does
226 input_location = new_map->start_location;
maybe this location isn't supposed to be expanded?
Or nothing is ever supposed to get this location?
For example changing the testcase to (invalid)
namespace js {}
# 9 "" 2
namespace js {
int a
}
results in
> ./cc1plus -quiet t.ii
line-map.c: file "<stdin>" left but not entered
t.ii:1048539:1: error: expected initializer before ‘}’ token
exposing those same bogus locations to the user.
Marking as libcpp issue. Note the bogus line info on the diagnostic
(and thus the underlying issue) is not a regression it seems (checked
up to GCC 4.1).
Not sure who's familiar with the C/C++ FE interfacing to libcpp and if
those "bogus" locations should simply never be assigned to input_location...
