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 ACA873AA8006; Fri, 13 Mar 2020 10:21:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ACA873AA8006
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1584094874;
 bh=2gFWeeEwe5MxR8zsttgTEp+wx24dc5Hbkr79mbIDGCg=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=VtM2facwX3e7GgAKlKPbRBvTs+4R6Bl1LxS3CObDE0MsYdHLZmL9JpoNIuQ3Xjw2r
 8UKTvO9XdPLU1DJ9LBHqOiKzvgUAt+5lzz5KeRQl1ToxLDMrpXZEVv8KEc4Xc4ijPc
 VHH8wJcZqDuncL+aKGKeNgN4i0mOSH7ptfNY0uyw=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/94162] ICE [neg] bad return type in defaulted <=>
Date: Fri, 13 Mar 2020 10:21:14 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 10.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
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: 
Message-ID: <bug-94162-4-cgvB8Q3BE8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94162-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94162-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: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://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: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 10:21:14 -0000

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It isn't clear to me what exactly disallows it, perhaps
http://eel.is/c++draft/class.spaceship#2.2
?
For auto return type
http://eel.is/c++draft/class.spaceship#4
defines what return type it should have.
If the explicit return type isn't auto, but is one of the
std::{strong,weak,partial}_ordering, we don't ICE and accept it, should we =
and
what behavior should it have?
#include <compare>
struct S {
  float a;
  std::strong_ordering operator<=3D>(const S&) const =3D default;
};
bool b =3D S{} < S{};
struct T {
  std::partial_ordering operator<=3D>(const T&) const =3D default;
};
bool c =3D T{} < T{};
For S, the auto return type would be std::partial_ordering and in the gener=
ated
body we just assume the floats will not be unordered.
So, for bool, shall it be accepted and handled some way, or shall it be
deleted, or result in immediate error (ill-formed)?
What about even weirder types (say float or int * or some arbitrary class)?=