https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #1) > Without the testcase it is hard to guess. > But one guess is that if in case of GC the cache is wiped and recreating it > may create something -fcompare-debug cares about (e.g. creation of new decls > - we care not about exact values of DECL_UID, but about their order), then > the deletable cache is a serious problem, because with -g and with -g0 there > is likely different amount of memory used, which means ggc_collect at > different times and thus we could be using the cache successfully with -g > and not without -g or vice versa. I'm having trouble imagining a scenario where the order of two decls changes due to the tables getting deleted. Clearing of the tables would cause copy_fn to get called a few more times in the subsequent constexpr call evaluations, causing later DECL_UIDs to be bigger but still in the same order I think. And I don't think the remapped decls of a copied constexpr function body could ever be visible to the callee so their particular DECL_UIDs shouldn't matter...
