public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/96299] New: Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
@ 2020-07-23 14:08 gcc-bugzilla at mysko dot org
2020-10-07 17:26 ` [Bug c++/96299] " mpolacek at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: gcc-bugzilla at mysko dot org @ 2020-07-23 14:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
@ 2020-10-07 17:26 ` mpolacek at gcc dot gnu.org
2020-11-15 0:44 ` gcc-bugzilla at mysko dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2020-10-07 17:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
2020-10-07 17:26 ` [Bug c++/96299] " mpolacek at gcc dot gnu.org
@ 2020-11-15 0:44 ` gcc-bugzilla at mysko dot org
2020-12-03 16:39 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: gcc-bugzilla at mysko dot org @ 2020-11-15 0:44 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
2020-10-07 17:26 ` [Bug c++/96299] " mpolacek at gcc dot gnu.org
2020-11-15 0:44 ` gcc-bugzilla at mysko dot org
@ 2020-12-03 16:39 ` jakub at gcc dot gnu.org
2020-12-08 20:13 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-12-03 16:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
` (2 preceding siblings ...)
2020-12-03 16:39 ` jakub at gcc dot gnu.org
@ 2020-12-08 20:13 ` cvs-commit at gcc dot gnu.org
2020-12-08 20:13 ` jason at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-12-08 20:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
` (3 preceding siblings ...)
2020-12-08 20:13 ` cvs-commit at gcc dot gnu.org
@ 2020-12-08 20:13 ` jason at gcc dot gnu.org
2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jason at gcc dot gnu.org @ 2020-12-08 20:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
` (4 preceding siblings ...)
2020-12-08 20:13 ` jason at gcc dot gnu.org
@ 2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-05-19 20:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
2020-07-23 14:08 [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
` (5 preceding siblings ...)
2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
@ 2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-05-19 20:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-05-19 20:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-23 14:08 [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
2020-10-07 17:26 ` [Bug c++/96299] " mpolacek at gcc dot gnu.org
2020-11-15 0:44 ` gcc-bugzilla at mysko dot org
2020-12-03 16:39 ` jakub at gcc dot gnu.org
2020-12-08 20:13 ` cvs-commit at gcc dot gnu.org
2020-12-08 20:13 ` jason at gcc dot gnu.org
2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
2021-05-19 20:17 ` cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).