From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id A1FAD3858C50; Fri,  8 Apr 2022 07:35:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1FAD3858C50
From: "falbrechtskirchinger at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/105200] New: user-defined operator <=> for enumerated types
 is ignored
Date: Fri, 08 Apr 2022 07:35:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: falbrechtskirchinger at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-105200-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2022 07:35:21 -0000

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

            Bug ID: 105200
           Summary: user-defined operator <=3D> for enumerated types is
                    ignored
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: falbrechtskirchinger at gmail dot com
  Target Milestone: ---

Version: g++
(Compiler-Explorer-Build-gcc-45fb78c9c456ace1d914c836d15af38ae345b902-binut=
ils-2.36.1)
12.0.1 20220407 (experimental)

Code:

#include <compare>
#include <iostream>

enum class foo { a, b, c, d };

inline std::partial_ordering operator<=3D>(const foo lhs, const foo rhs) {
        std::cout << "foo <=3D> called\n";
        return std::partial_ordering::less;
}

int main() {
        std::cout << std::boolalpha;

        bool b1 =3D foo::b < foo::a;
        std::cout << "foo::b < foo::a :=3D " << b1 << "\n";

        std::cout << "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n";

        bool b2 =3D std::is_lt(foo::b <=3D> foo::a);
        std::cout << "std::is_lt(foo::b <=3D> foo::a) :=3D " << b2 << "\n";
}

Comparison of GCC, Clang, MSVC, ICC:
https://godbolt.org/z/n7GnqhMvn


GCC (apparently) always selects the builtin operator <=3D> for enumerated t=
ypes
and ignores the user-defined one. GCC's behavior differs from Clang, MSVC, =
and
ICC (although the latter, despite calling user-defined <=3D>, still produce=
s the
wrong result).

Of course defining the regular comparison operators works as intended and so
this different behavior with user-defined <=3D> seems inconsistent, even if=
 it
can be argued that it is to letter of the standard (see [expr.spaceship] on
comparing enumerated types). I disagree with this reading of the standard o=
ver
all.

Discussing this on IRC and referring to sections [expr.spaceship],
[over.built], [over.match.oper], and [over.match.best] of the standard no
consensus was reached as to which implementation is correct and I was asked=
 to
open this bug report.

As a reminder to myself: Trying to find a workaround, I deleted operator <
which resulted in a segfault. I should try to re-create this ICE and file a
separate bug.=