[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2020-05-21 00:00:00 |2021-8-4 --- Comment #5 from Andrew Pinski --- (In reply to Marc Glisse from comment #1) > It looks like clang-10+ also generates an infinite loop on this code. clang 12+ now does not produce an infinite loop. GCC trunk still does though.
[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141 --- Comment #4 from Laurent Rineau --- (In reply to Marc Glisse from comment #3) > It seems that this is as currently specified in C++20, but that some people > are going to try and change the rules to avoid breaking code like this. Do you have reference to the discussion on the subject?
[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141 Marc Glisse changed: What|Removed |Added Last reconfirmed||2020-05-21 Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 --- Comment #3 from Marc Glisse --- It seems that this is as currently specified in C++20, but that some people are going to try and change the rules to avoid breaking code like this.
[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141 --- Comment #2 from Marc Glisse --- Ah, maybe the friend function is not quite a template, so the generated swapped function is not a template either, and thus it has priority over a template if both are exact matches? This is going to break a number of users of boost/operators.hpp, and possibly other mixins using a similar technique.
[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141 --- Comment #1 from Marc Glisse --- It looks like clang-10+ also generates an infinite loop on this code. Does the standard really give priority to some implicit function over a user-defined one that is an exact match?