https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125555
--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> --- Created attachment 64949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64949&action=edit broken initial attempt (In reply to Patrick Palka from comment #2) > The following reduced testcase never worked: The issue here seems to be that 1) we don't add op==<__ni<int>,__ni<int>> as a pending specialization to any key, so we don't load it until we see the use of it in foo(), at which point we've already created another decl for it. And then 2) we fail to merge the loaded specialization with the existing one. If op== were a member template instead of a hidden friend, we'd get Pending specialization '::__normal_iterator<int>::template operator==<_Iter>' entity:4 section:2 also keyed to '::__normal_iterator' Pending specialization '::__normal_iterator<int>::operator==<::__normal_iterator<int>>' entity:7 section:3 keyed to '::__normal_iterator' This lack seems to be because add_specializations completely ignores friends; the existing code is clearly wrong, as it calls template_args_equal to compare template arguments to a template rather than another set of template arguments. My initial attempt to fix that breaks reading key.constraints in key_mergeable for some reason I haven't had a chance to investigate yet.
