https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> --- OK, the bug reproduces with tree.c changes reverted and I see what is going on. We have two files in res file we get: 2 lines.o 7 245 4d647b2020ca5815 PREVAILING_DEF_IRONLY _Z8validatev 334 4d647b2020ca5815 PREVAILING_DEF_IRONLY _Z15validate_valuesB5cxx11 201 4d647b2020ca5815 RESOLVED_DYN __gxx_personality_v0 329 4d647b2020ca5815 RESOLVED_DYN _ZTIi 247 4d647b2020ca5815 RESOLVED_DYN __cxa_end_catch 252 4d647b2020ca5815 RESOLVED_DYN __cxa_begin_catch 315 4d647b2020ca5815 UNDEF _ZN5boost8any_castINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEET_NS_1BE options.o 17 333 822251a199041d42 PREVAILING_DEF_IRONLY _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev 328 822251a199041d42 PREVAILING_DEF _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev 398 822251a199041d42 PREVAILING_DEF_IRONLY _ZGVZN5boost15program_options17get_single_stringIcEEvSt1AINSt7__cxx1112basic_stringIT_St11char_traitsIS5_ESaIS5_EEEEE5emptyB5cxx11 403 822251a199041d42 PREVAILING_DEF_IRONLY _ZZN5boost15program_options17get_single_stringIcEEvSt1AINSt7__cxx1112basic_stringIT_St11char_traitsIS5_ESaIS5_EEEEE5emptyB5cxx11 355 822251a199041d42 PREVAILING_DEF_IRONLY _ZNK5boost15program_options11typed_valueIicE6xparseERiRKSt1AINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE 358 822251a199041d42 PREVAILING_DEF main 306 822251a199041d42 PREVAILING_DEF_IRONLY _ZTVN5boost15program_options11typed_valueIicEE 413 822251a199041d42 PREVAILING_DEF_IRONLY _ZTSN5boost15program_options11typed_valueIicEE 434 822251a199041d42 PREVAILING_DEF_IRONLY _ZTIN5boost15program_options11typed_valueIicEE 405 822251a199041d42 RESOLVED_EXEC __dso_handle 445 822251a199041d42 RESOLVED_DYN _ZTVN10__cxxabiv120__si_class_type_infoE 452 822251a199041d42 UNDEF _ZTIN5boost15program_options29value_semantic_codecvt_helperIcEE 364 822251a199041d42 RESOLVED_DYN __cxa_guard_abort 374 822251a199041d42 RESOLVED_DYN __cxa_atexit 377 822251a199041d42 RESOLVED_DYN __cxa_guard_release 380 822251a199041d42 RESOLVED_DYN _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev 385 822251a199041d42 RESOLVED_DYN __cxa_guard_acquire Now problem is that after streaming in we have resolution of _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev set as UNKNOWN. This is inconsistent across comdat group and triggers funny behaviour of ipa-visibility that eventually leads to wrong code. The problem is that we definitly should not lose resolution information. In most cases we get around silently but produce bad code. What happens is that the decl is registered when streaming in lines.o. This is because the decl is there and referenced by debug info only. At this time we see no resolution info and set it as UNKNOWN. While streaming in the second file (options.o) we never set the resolution becuase unify_scc return true and thus we bypass call to lto_register_function_decl_in_symtab. I wonder what should we do. Perhaps make lto_register_function_decl_in_symtab nothing when resolution is UNKNOWN and call it even in case unify_scc suceeded? This will need another loop at in quite hot region of streaming. Richi, do you have better ideas?
