Hi, I am observing a memory error with gcc 8.3: Compiling a large C++ file (~8000 lines) with -fdebug-prefix-map=/user/path/obj=../obj and -gsplit-dwarf results in an object which does not store the specified "../obj" but a string like "SR.7568". This seems to be related to the ggc garbage collector, a quick test making ggc_collect() a no-op solves the problem. The corruption shows up in comp_dir_string() [dwarf2out.c: 20702]. There the `static const char* cached_wd` is first set to the correct "../obj". This string is returned from remap_debug_filename() [file-prefix-map.c:129] which in turn was allocated by ggc_alloc_atomic(). When comp_dir_string() is called again the cached string is corrupted. In one case I could trace this back to ht_lookup_with_hash() / table->alloc_subobject() [libcpp/symtab.c:163]. There table->alloc_subobject is set to stringpool_ggc_alloc() which is a wrapper for ggc_alloc_atomic(). This returned the same address as was stored in `cached_wd`, resulting in "../obj" changing to "SR.7568". I tried to annotate `cached_wd` via GTY((..)) as on first glance it seems the gc mistakenly re-uses it, but the `gengtype` generated state file never picks this variable up. The annoying part is that this bug is hard to reproduce, most other input files do not trigger it and even adding debug code or not compiling with -O2 make it disappear sometimes. Explicitly calling `ggc_force_collect = true; ggc_collect(); ggc_force_collect = false;` right after setting cached_wd does not trigger it. However gcc 8.2 and 8.1 built with the same setup (gcc 4.9.3) also show this problem. Can someone with more gc experience look at this and decide if this is an actual bug? Otherwise I would just point cached_wd to non-gc memory and store the value there, but maybe I stumbled on a rare yet brittle corner case. Thanks & Regards Thomas
