[Bug c++/95567] New: Defaulted virtual <=> has the wrong behavior

[Bug c++/95567] New: Defaulted virtual <=> has the wrong behavior

[barry.revzin at gmail dot com]

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

            Bug ID: 95567
           Summary: Defaulted virtual <=> has the wrong behavior
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from Twitter user @feder_and_ink:

#include <compare>

struct B {
  B(int i) : i(i) {}

  VIRTUAL std::strong_ordering operator<=>(B const& other) const = default;
  int i;
};

struct D : B {
  D(int i, int j) : B(i), j(j) {}
  int j;
};

bool check() {
    return B(2) == D(2, 3);
}

With -DVIRTUAL=, check() returns true.
With -DVIRTUAL=virtual, check() erroneously returns false.
On compiler explorer: https://godbolt.org/z/hc3U5f

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin <barry.revzin at gmail dot com> ---
To follow up on this, it's not the operator<=> being virtual that's significant
but rather the class itself being polymorphic. This exhibits the same behavior:

#include <compare>

struct B {
  B(int i) : i(i) {}
  VIRTUAL ~B() = default;

  std::strong_ordering operator<=>(B const& other) const = default;
  int i;
};

struct D : B {
  D(int i, int j) : B(i), j(j) {}
  int j;
};

bool check() {
    return B(2) == D(2, 3);
}

https://godbolt.org/z/ZFqB59

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-10-28

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2020-10-28 00:00:00         |2021-8-10
            Summary|Defaulted virtual <=> has   |Defaulted virtual <=> has
                   |the wrong behavior          |the wrong behavior, vtable
                   |                            |is checked when it should
                   |                            |not be

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Right it is checking the vtable for equality.

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

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

commit r12-3995-gb6bca2e631b54f992c058ca8e445b45e9816690b
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Sep 30 17:29:05 2021 -0400

    c++: defaulted comparisons and vptr fields [PR95567]

    We need to explicitly skip over vptr fields when synthesizing a
    defaulted comparison operator, because next_initializable_field
    doesn't do so for us.

            PR c++/95567

    gcc/cp/ChangeLog:

            * method.c (build_comparison_op): Skip DECL_VIRTUAL_P fields.

    gcc/testsuite/ChangeLog:

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

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

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

commit r11-9084-ge84436a273f0fbb42b9785ff5bb1deaf9a500f37
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Sep 30 17:29:05 2021 -0400

    c++: defaulted comparisons and vptr fields [PR95567]

    We need to explicitly skip over vptr fields when synthesizing a
    defaulted comparison operator, because next_initializable_field
    doesn't do so for us.

            PR c++/95567

    gcc/cp/ChangeLog:

            * method.c (build_comparison_op): Skip DECL_VIRTUAL_P fields.

    gcc/testsuite/ChangeLog:

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

    (cherry picked from commit b6bca2e631b54f992c058ca8e445b45e9816690b)

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 11.3 and 12.