https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118387
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |redi at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Yihe Li from comment #0)
> However, after throwing the usual defaulted as delete error, GCC trunk then
> ICEs. Note that ICE does not happen on GCC 14.2, which just exits after
> printing the first two error messages.
That is not the case. GCC 12-14 ICE the same, just in
--enable-checking=release
gcc emits for error recovery
confused by earlier errors, bailing out
message instead of the ICE message.
> Also, perhaps a related bug: if you just omit the member b and try to define
> `int operator<=>(const A&) const = default;` for an empty struct A, instead
> of defaulting as deleted as it should, the program compiles but immediately
> crashes when run since the generated <=> body contains an ud2 instruction.
> This is not a 15 regression but seems to be a bug that dates back to GCC 10
> where <=> was first supported. See https://godbolt.org/z/T56GacWvv.
Why do you think it should be deleted?
https://eel.is/c++draft/class.compare#class.spaceship-2.2
talks about when it is deleted if there are any members, but in this case there
aren't any.
For no members, if the declared return type was auto, it would be
std::strong_ordering
as per https://eel.is/c++draft/class.compare#class.spaceship-4.3
but because it is explicitly int, I think per
https://eel.is/c++draft/class.compare#class.spaceship-3
it should return
static_cast<int>(std::strong_ordering::equal)
but that isn't valid.
