https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> --- The checks that we do replace definition by non-defition in symbol merging. =Would be possible to bisect this? GCC 8 produces: _ZTVN10__cxxabiv117__class_type_infoE/1 (_ZTVN10__cxxabiv117__class_type_infoE) @0x7ffff69e1180 Type: variable Body removed by symtab_remove_unreachable_nodes Visibility: externally_visible no_reorder undef external public weak comdat comdat_group:_ZTVN10__cxxabiv117__class_type_infoE one_only virtual artificial next sharing asm name: 12 References: Referring: _ZTI1b/4 (addr) Read from file: 1.o Availability: not-ready Varpool flags: initialized read-only const-value-known _ZTVN10__cxxabiv117__class_type_infoE/12 (_ZTVN10__cxxabiv117__class_type_infoE) @0x7ffff69e1380 Type: variable definition analyzed Visibility: externally_visible undef external public weak comdat comdat_group:_ZTVN10__cxxabiv117__class_type_infoE one_only virtual artificial previous sharing asm name: 1 References: _ZTIN10__cxxabiv117__class_type_infoE/14 (addr)_ZN1a1bEv/18 (addr) Referring: _ZTI1c/15 (addr) Read from file: 2.o Availability: not-ready Varpool flags: initialized read-only const-value-known and has resolution info 2 1.o 6 221 4a2d2cb92dbf08ab PREVAILING_DEF_IRONLY _ZNK1b1cEv 235 4a2d2cb92dbf08ab PREVAILING_DEF_IRONLY _ZTS1b 251 4a2d2cb92dbf08ab PREVAILING_DEF_IRONLY _ZTI1b 275 4a2d2cb92dbf08ab PREVAILING_DEF_IRONLY _ZTV1b 201 4a2d2cb92dbf08ab UNDEF __gxx_personality_v0 270 4a2d2cb92dbf08ab UNDEF _ZTVN10__cxxabiv117__class_type_infoE 2.o 5 230 6b69d9d40039828d PREVAILING_DEF_IRONLY _ZNK1c5m_fn2Ev 259 6b69d9d40039828d PREVAILING_DEF_IRONLY _ZTS1c 274 6b69d9d40039828d PREVAILING_DEF_IRONLY _ZTI1c 210 6b69d9d40039828d PREVAILING_DEF_IRONLY _ZTV1c 282 6b69d9d40039828d UNDEF _ZTVN10__cxxabiv117__class_type_infoE same happens for trunk but it happens to work. so it may be just wrong handling of UNDEF symbol in the symtab.
