[Bug c++/98712] New: Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting

[Bug c++/98712] New: Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting

[ryan_greenblatt at brown dot edu]

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

            Bug ID: 98712
           Summary: Incorrect defaulted operator== at compile time and
                    runtime when declared constexpr and inheriting
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ryan_greenblatt at brown dot edu
  Target Milestone: ---

```
struct IntHolder {
  int v;
  bool operator==(const IntHolder &) const = default;
};

struct Inherits : IntHolder {
  // without constexpr here the issue goes away...
  constexpr bool operator==(const Inherits &) const = default;
};

#if 0
static_assert(Inherits{1} != Inherits{2});
#else
#include <iostream>

int main() {
  // should output true...
  volatile int l = 1;
  std::cout << std::boolalpha << (Inherits{l} != Inherits{2}) << std::endl;
}
#endif
```
https://godbolt.org/z/145dbq

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[ryan_greenblatt at brown dot edu]

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

--- Comment #1 from Ryan Greenblatt <ryan_greenblatt at brown dot edu> ---
I've also noticed some incorrect compiler errors when trying to default
constexpr operator== in similar circumstances. I think the causes are the
likely the same.

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-01-19
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed.

It seems that when operator== is declared constexpr, we synthesize it eagerly
from check_bases_and_members before doing layout_class_type, which means that
at the point of synthesis the type's TYPE_FIELDS lacks the FIELD_DECLs that
correspond to its bases, so build_comparison_op ends up completely ignoring the
type's bases.

When operator== is not declared constexpr, we synthesize the method lazily at
the point of first use, and thus well after layout_class_type has been done
from finish_struct_1.

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barry.revzin at gmail dot com

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 100835 has been marked as a duplicate of this bug. ***

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |myosotis at mail dot ustc.edu.cn

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 101888 has been marked as a duplicate of this bug. ***

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Similarly for
#include <compare>

struct S
{
    int s = 0;
    S(int s) : s(s) {}
    auto operator<=>(const S&) const = default;
};

struct T : S
{
    T(int s) : S(s) {}
    constexpr auto operator<=>(const T&) const = default;
};

int main() { return T(0) >= T(1); } // Expected 0, but returns 1

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[cvs-commit at gcc dot gnu.org]

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

--- 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:09d886e671f2230acca082e6579a69b8df8fb202

commit r12-4202-g09d886e671f2230acca082e6579a69b8df8fb202
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Oct 1 17:07:17 2021 +0200

    c++: defaulted <=> with bitfields [PR102490]

    The testcases in the patch are either miscompiled or ICE with checking,
    because the defaulted operator== is synthesized too early (but only if
    constexpr), when the corresponding class type is still incomplete type. 
The
    problem is that at that point the bitfield FIELD_DECLs still have as
    TREE_TYPE their underlying type rather than integral type with their
    precision and when layout_class_type is called for the class soon after
    that, it changes those types but the COMPONENT_REFs type stay the way that
    they were during the operator== synthesize_method type and the middle-end
is
    then upset by the mismatch of types.  As what exact type will be given
isn't
    just a one liner but quite long code especially for over-sized bitfields, I
    think it is best to just not synthesize the comparison operators so early
    and call defaulted_late_check for them once again as soon as the class is
    complete.

    This is also a problem for virtual operator<=>, where we need to compare
the
    noexcept-specifier to validate the override before the class is complete.
    Rather than try to defer that comparison, maybe_instantiate_noexcept now
    calls maybe_synthesize_method, which calls build_comparison_op in
    non-defining mode if the class isn't complete yet.  In that situation we
    also might not have base fields yet, so we look in the binfo for the bases.

    Co-authored-by: Jason Merrill <jason@redhat.com>

    2021-10-01  Jakub Jelinek  <jakub@redhat.com>

            PR c++/98712
            PR c++/102490
            * cp-tree.h (maybe_synthesize_method): Declare.
            * method.c (genericize_spaceship): Use
            LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
            LOOKUP_NORMAL for flags.
            (comp_info): Remove defining member.  Add complain, code, retcat.
            (comp_info::comp_info): Adjust.
            (do_one_comp): Split out from build_comparison_op.   Use
            LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
            LOOKUP_NORMAL for flags.
            (build_comparison_op): Add defining argument. Adjust comp_info
            construction.  Use defining instead of info.defining.  Assert that
            if defining, ctype is a complete type.  Walk base binfos.
            (synthesize_method, maybe_explain_implicit_delete,
            explain_implicit_non_constexpr): Adjust build_comparison_op
callers.
            (maybe_synthesize_method): New function.
            * class.c (check_bases_and_members): Don't call
defaulted_late_check
            for sfk_comparison.
            (finish_struct_1): Call it here instead after class has been
            completed.
            * pt.c (maybe_instantiate_noexcept): Call maybe_synthesize_method
            instead of synthesize_method.

            * g++.dg/cpp2a/spaceship-synth8.C (std::strong_ordering): Provide
            more complete definition.
            (std::strong_ordering::less, std::strong_ordering::equal,
            std::strong_ordering::greater): Define.
            * g++.dg/cpp2a/spaceship-synth12.C: New test.
            * g++.dg/cpp2a/spaceship-synth13.C: New test.
            * g++.dg/cpp2a/spaceship-synth14.C: New test.
            * g++.dg/cpp2a/spaceship-eq11.C: New test.
            * g++.dg/cpp2a/spaceship-eq12.C: New test.
            * g++.dg/cpp2a/spaceship-eq13.C: New test.

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |delleyves at gmx dot ch

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 104785 has been marked as a duplicate of this bug. ***

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |12.0
             Status|NEW                         |RESOLVED

--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Thus fixed since GCC 12