https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489
--- Comment #7 from DV Henkel-Wallace ---
Thanks. That is clear.
BTW FWIW, defining <=> myself and then defining == default does appear to do
what I want (i.e. I don't have to use. = default with both operators). I saw
that cppreference claims
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489
--- Comment #5 from DV Henkel-Wallace ---
(In reply to Jonathan Wakely from comment #4)
> I believe the rationale for this is that if your <=> can't be defaulted,
> then it must be doing something special, and synthesizing == from it is not
> nec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489
--- Comment #2 from DV Henkel-Wallace ---
I don't think this should be marked as resolved. The bug is not the case you
cited which indeed works properly as specified.
The bug is that comparators are not being synthesized when the a *user
suppli
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gu...@henkel-wallace.org
Target Milestone: ---
User-defined <=> doesn't generate == or != though user-defined operator== and
operator<=> = default do.
/usr/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96278
--- Comment #2 from DV Henkel-Wallace ---
(In reply to Andrew Pinski from comment #1)
> I think this is a dup of bug 95242.
Could be: I'm not sure if Jason's change applies only to synthesized
comparators or not (that was the case described in 9
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gu...@henkel-wallace.org
Target Milestone: ---
Bug in g++ 10.1.0 with libstdc++
compile following program doing `g++-10 -std=c++20
-Wzero-as-null-pointer-constant`
#include
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gu...@henkel-wallace.org
Target Milestone: ---
Given this file:
===
enum class e { a, b, c};
int converter (e val);
int converter (e val) {
switch
