https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91935
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |lto
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-10-01
CC| |marxin at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Component|c++ |lto
Ever confirmed|0 |1
Known to fail| |10.0, 8.3.0, 9.2.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We end up with "removed" symbols not reclaimed:
Symbol table '.symtab' contains 64 entries:
Num: Value Size Type Bind Vis Ndx Name
...
40: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
41: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
42: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
43: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
44: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
45: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
46: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
47: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
48: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
49: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
50: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24
51: 0000000000000000 0 FILE LOCAL DEFAULT ABS
52: 000000000000006b 0 NOTYPE LOCAL DEFAULT 24 foo.c.ec31ca56
there doesn't seem to be an easy portable way of "making" symtab entries
that the link editor can elide (I would have expected it would at least
commonize the above). Implementing symtab pruning in simple-object-elf.c
while doable looks like another chunk of "useless" work :/
