[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

[jakub at gcc dot gnu.org]

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.