On Fri, 9 Oct 2026, Longjun Luo wrote: > Hi Richard, > > Ping on v4: > https://inbox.sourceware.org/gcc-patches/[email protected]/
Sorry for the delay - I tend to post-pone those heavy-thinking patches ... :/ > I have some additional data and a revision planned. In an -O2 -g -flto > test of 12 GCC source files (base 543617c93595), v4 reduced cross-CU > parent/child abstract-origin mismatches from 5,751 of 17,160 checked > concrete function/inline DIEs to 11. In a runnable reproducer, the > mismatch makes GDB display duplicate parameters and local variables. > > v4 still needs a correction: its origin-pointer check can discard an > edge reference that is still valid, since prevailing-decl replacement > does not change which TU supplied the owner's children. I reproduced > this with a COMDAT function kept in several TUs that were compiled > with different options. > > For v5, I plan to remove that check and add a regression test, make > the side table weak-keyed to reduce memory retention, and simplify > copy_lto_abstract_origin_ref to propagate only existing edge > references. > > The remaining 11 cases involve merged COMDAT functions whose prevailing > body and retained early DIE come from different TUs. I would leave > those for a follow-up unless you prefer otherwise. Yeah, it seems this is a somewhat different class. > Does this direction look reasonable? I'd appreciate your advice > before posting v5. Yes. See the review comments, I'm mostly concerned about the dref_queue thingy (and of course have the wishful thinking that an entirely different representation than tree of abstract origins would be cleaner). Thanks and sorry again for the delay, Richard. > Thanks, > Longjun > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
