https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, as this is lto1, all the locations are created by
lto_location_cache::apply_location_cache.
With -g lto1 can stream more locations than with -g0, and apply_location_cache
is always called on some chunk of locations before we really need them, qsorts
the expanded locations and emits them into line_table.
current_{file,line,col,sysp} are left after this call pointing to the last
entry added by apply_location_cache in following processing. Locations that
match it will get LOCATION_LOCUS of current_loc, while otherwise they will be
pushed into processing by next apply_location_cache.
On this testcase (I'm actually working with:
# 6 ""
short a;
__attribute__((optimize(0))) int foo ();
__attribute__((always_inline)) signed char bar ();
int foo () {
char e = bar ();
return a;
}
signed char bar (f) {
baz ();
# 7 "pr104237-2.c"
int g;
# 6
return f;
}
void baz () {}
int main () { return 0; }
) what happens is that on the second apply_location_cache call, with -g0 we
have 14 entries in loc_cache, while with -g 16 entries, the last two extra ones
after qsort come last. So, when lto_location_cache::input_location_and_block
is called after this block, if it wants a location that was last with -g0 but
not with -g, it will reuse the last emitted entry in one case and not in the
other one and vice versa.
The extra 2 entries are in particular the g in int g;
So, I think either we need some much more expensive way to ensure we never have
duplicate locations from the LTO streaming in, or we need to use
expand_location content comparisons instead of (or in addition to) location_t
comparisons.
