https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68138
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=93147
CC| |ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> The original testcase and the one in comment #2 started to work in GCC 11+.
I suspect by r11-2720 aka the fix for PR libstdc++/93147.
(In reply to Harald van Dijk from comment #3)
> Here's a reduced standalone testcase, no libstdc++.
>
> struct Empty { bool operator==(Empty); };
> class tuple_impl : Empty {};
> class tuple : tuple_impl, Empty {};
> bool operator==(tuple, tuple);
> int main() { tuple a, b; a == b; }
>
> tuple derives from Empty twice and would inherit its operator==(Empty)
> member function, except any attempt to use it would be ambiguous. GCC and
> Intel reject this, clang and MSVC accept it using the global
> operator==(tuple, tuple). If tuple only inherits from Empty once, then all
> compilers are in agreement that operator==(tuple, tuple) is a better match
> than the operator==(Empty) member function.
IIUC the ambiguous member lookup makes this example ill-formed, despite the
global operator== otherwise being a better candidate than Empty::operator==.
