[Bug c++/96299] New: Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[Bug c++/96299] New: Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[gcc-bugzilla at mysko dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

            Bug ID: 96299
           Summary: Defaulted operator <=> implicitly deleted when a
                    member has operator < and operator == and return type
                    is specified
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugzilla at mysko dot org
  Target Milestone: ---

The following sample fails to compile with GCC 10.1 and with trunk as of
2020-07-22.

===================
#include <compare>

struct Legacy
{
  bool operator==(Legacy const&) const;
  bool operator<(Legacy const&) const;
};

struct A
{
  std::strong_ordering operator <=> (A const& other) const = default;
  Legacy l;
};

int main()
{
  A a, b;

  return a < b;    
}
===================

With the following error:
<source>: In function 'int main()':

<source>:19:14: error: use of deleted function 'constexpr std::strong_ordering
A::operator<=>(const A&) const'

   19 |   return a < b;

      |              ^

<source>:11:24: note: 'constexpr std::strong_ordering A::operator<=>(const A&)
const' is implicitly deleted because the default definition would be
ill-formed:

   11 |   std::strong_ordering operator <=> (A const& other) const = default;

      |                        ^~~~~~~~

<source>:11:24: error: no match for 'operator<=>' (operand types are 'Legacy'
and 'Legacy')


>From my understanding of p1186r3
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1186r3.html) the code
should be accepted. The GCC standards support table lists p1186r3 as
implemented in GCC 10. According to p1186r3, the defaulted operator <=> should
use the member's < and == operators if the return type is specified
(strong/weak/partial), and should not require a <=> operator for the member.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-10-07
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[gcc-bugzilla at mysko dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

henrik <gcc-bugzilla at mysko dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc-bugzilla at mysko dot org

--- Comment #2 from henrik <gcc-bugzilla at mysko dot org> ---
I suggest that support for P1186R3 should not be advertised as available in GCC
at https://gcc.gnu.org/projects/cxx-status.html until this bug is resolved. 

The status page is a bit misleading since no example of the P1186R3 paper works
(as far as I know).

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |jakub at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at this now.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:4ed1dc1275bba89af92bfc7d97c21b376e4c29c3

commit r11-5866-g4ed1dc1275bba89af92bfc7d97c21b376e4c29c3
Author: Jason Merrill <jason@redhat.com>
Date:   Fri Dec 4 21:48:43 2020 -0500

    c++: Fix defaulted <=> fallback to < and == [PR96299]

    I thought I had implemented P1186R3, but apparently I didn't read it
closely
    enough to understand the point of the paper, namely that for a defaulted
    operator<=>, if a member type doesn't have a viable operator<=>, we will
use
    its operator< and operator== if the defaulted operator has an specific
    comparison category as its return type; the compiler can't guess if it
    should be strong_ordering or something else, but the user can make that
    choice explicit.

    The libstdc++ test change was necessary because of the change in
    genericize_spaceship from op0 > op1 to op1 < op0; this should be
equivalent,
    but isn't because of PR88173.

    gcc/cp/ChangeLog:

            PR c++/96299
            * cp-tree.h (build_new_op): Add overload that omits some parms.
            (genericize_spaceship): Add location_t parm.
            * constexpr.c (cxx_eval_binary_expression): Pass it.
            * cp-gimplify.c (genericize_spaceship): Pass it.
            * method.c (genericize_spaceship): Handle class-type arguments.
            (build_comparison_op): Fall back to op</== when appropriate.

    gcc/testsuite/ChangeLog:

            PR c++/96299
            * g++.dg/cpp2a/spaceship-synth-neg2.C: Move error.
            * g++.dg/cpp2a/spaceship-p1186.C: New test.

    libstdc++-v3/ChangeLog:

            PR c++/96299
            * testsuite/18_support/comparisons/algorithms/partial_order.cc:
            One more line needs to use VERIFY instead of static_assert.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for GCC 11.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:cd67343703ef4fa61de837f4690eba70d2760825

commit r12-928-gcd67343703ef4fa61de837f4690eba70d2760825
Author: Jason Merrill <jason@redhat.com>
Date:   Tue May 18 12:29:33 2021 -0400

    c++: ICE with <=> fallback [PR100367]

    Here, when genericizing lexicographical_compare_three_way, we haven't yet
    walked the operands, so (a == a) still sees ADDR_EXPR <a>, but this is
after
    we've changed the type of a to REFERENCE_TYPE.  When we try to fold (a ==
a)
    by constexpr evaluation, the constexpr code doesn't understand trying to
    take the address of a reference, and we end up crashing.

    Fixed by avoiding constexpr evaluation in genericize_spaceship, by using
    fold_build2 instead of build_new_op on scalar operands.  Class operands
    should have been expanded during parsing.

            PR c++/100367
            PR c++/96299

    gcc/cp/ChangeLog:

            * method.c (genericize_spaceship): Use fold_build2 for scalar
            operands.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/spaceship-fallback1.C: New test.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jason Merrill
<jason@gcc.gnu.org>:

https://gcc.gnu.org/g:3bdd3e45955ef94a1f2db51a2af1ded54d41f670

commit r11-8437-g3bdd3e45955ef94a1f2db51a2af1ded54d41f670
Author: Jason Merrill <jason@redhat.com>
Date:   Tue May 18 12:29:33 2021 -0400

    c++: ICE with <=> fallback [PR100367]

    Here, when genericizing lexicographical_compare_three_way, we haven't yet
    walked the operands, so (a == a) still sees ADDR_EXPR <a>, but this is
after
    we've changed the type of a to REFERENCE_TYPE.  When we try to fold (a ==
a)
    by constexpr evaluation, the constexpr code doesn't understand trying to
    take the address of a reference, and we end up crashing.

    Fixed by avoiding constexpr evaluation in genericize_spaceship, by using
    fold_build2 instead of build_new_op on scalar operands.  Class operands
    should have been expanded during parsing.

            PR c++/100367
            PR c++/96299

    gcc/cp/ChangeLog:

            * method.c (genericize_spaceship): Use fold_build2 for scalar
            operands.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/spaceship-fallback1.C: New test.