https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Created attachment 35100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35100&action=edit partial patch Hi, this is a patch that adds necessary checks into resolution code. Basically if static linking is anticipated, we can not derive much of useful info from PREVAILING_DEF/PREVAILING_DEF_IRONLY_EXP and must anticipate that static linking may change these and drop comdat groups. THe catch is that someone needs to pass -r to lto1 that is not currently happening (I verified that if I hack opts.c to set incremental_linking to true the testcase works). With -r option, I can imagine that lto-wrapper can do it, because we get: COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' '-fno-trapv' '-fno-openmp' '-fno-openacc' '-mtune=generic' '-march=x86-64' '-O2' '-B' './' '-O2' '-r' '-v' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/cc3o3UIr.ltrans.out' '-fwpa' '-fresolution=/tmp/cchYXuvF.res I donot know hwere -r gets dropped though. But the testcase uses -Wl,-r that may need LTO plugin extension?
