From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 4AB673858CDB; Sun,  4 Feb 2024 18:57:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4AB673858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1707073050;
	bh=1OJiSHoX6Y71dVd3Qu4XbRuC59DUpOnkftuD98QL5sk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=GfN0g94EkI7lzHNzF31CjqhYN2MR/Ml6VB4ZX590kvpEEf2cX+3AEcFuh4tTtof3u
	 j7B+EEXsxrl608EdVEZKoHoA+zpy7jywKWXpw1Mhy8hvVIcYG1EzRfQwcULnqHMpn7
	 UBsIH2K0sCyx9rsRM9PExjMKlMV1meXn17/hZz+E=
From: "simon.marchi at polymtl dot ca" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/31331] Wenum-constexpr-conversion should be fixed, soon
 treated as a hard error
Date: Sun, 04 Feb 2024 18:57:29 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: simon.marchi at polymtl dot ca
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-31331-4717-AuxFZTzUqP@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-31331-4717@http.sourceware.org/bugzilla/>
References: <bug-31331-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D31331

--- Comment #4 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Tom Tromey from comment #2)
> I changed enum-flags.h to use std::underlying_type, with the idea
> that if there were any errors, I'd simply change the base
> enum to use an unsigned type.  (I tried auditing the existing
> uses by hand but I lost interest partway through.)

I think that the code explicitly avoids using underlying_type on the enum t=
ype,
to get around this behavior (I'll paste the code to generate this table at =
the
end).

Type             is_signed_v<T>      T(-1)  T(0)  T(-1) < T(0)
Implicit         false                  -1     0  true=20=20
ExplicitSigned   true                   -1     0  true=20=20
ExplicitUnsigned false          4294967295     0  false=20

That is, an enum that doesn't specific a base type (Implicit above) has
unsigned underlying type, according to std::underlying_type, but it decays =
to
an integer, it appears to behave like a signed type (perhaps some language =
guru
can explain why).

The expression "T (-1) < T (0)" in enum-flags.h is ultimately used to defin=
ed
the traits type EnumIsUnsigned and EnumIsSigned.  And those are used to ena=
ble
or disable the use of operator~ on enum / enum flag types that behave like
signed types.  I guess because operator~ is not well-defined for them?

So by doing the std::underlying_type change, here's the difference.  Without
your change, trying to use operator~ on let's say STEP_OVER_BREAKPOINT would
give:

  CXX    infrun.o
/home/simark/src/binutils-gdb/gdb/infrun.c:1470:12: error: overload resolut=
ion
selected deleted operator '~'
  auto x =3D ~STEP_OVER_BREAKPOINT;
           ^~~~~~~~~~~~~~~~~~~~~
/home/simark/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:408:16: note:
candidate function [with enum_type =3D step_over_what_flag, $1 =3D void, $2=
 =3D void]
has been explicitly deleted
constexpr void operator~ (enum_type e) =3D delete;
               ^

If I change the enum_underlying_type definition to be:

template<typename T>
struct enum_underlying_type
{
  typedef typename integer_for_size<
    sizeof (T), static_cast<bool> (
                  std::is_signed_v<std::underlying_type_t<T>>)>::type type;
};

... then the use of operator~ is allowed.

I don't know if this complexity is needed in the end, I just wanted to expl=
ain
why (if I understand correctly) we have what we have today.

---

#include <fmt/core.h>
#include <sstream>

enum Implicit {
  A1 =3D 1,
  A2 =3D 2,
  A3 =3D 4,
};
enum ExplicitSigned : signed {
  B1 =3D 1,
  B2 =3D 2,
  B3 =3D 4,
};
enum ExplicitUnsigned : unsigned {
  C1 =3D 1,
  C2 =3D 2,
  C3 =3D 4,
};

template <typename T> void printInfosAboutT(const char *typeName) {
  fmt::print("{: <16} ", typeName);
  fmt::print("{: <14} ", std::is_signed_v<std::underlying_type_t<T>>);

  {
    std::ostringstream os;
    os << T(-1);
    fmt::print("{: >10}  ", os.str());
  }

  {
    std::ostringstream os;
    os << T(0);
    fmt::print("{: >4}  ", os.str());
  }=20

  fmt::print("{: <5} ", T(-1) < T(0));
  fmt::print("\n");
}

int main() {
  fmt::print("Type             is_signed_v<T>      T(-1)  T(0)  T(-1) <
T(0)\n");
  printInfosAboutT<Implicit>("Implicit");
  printInfosAboutT<ExplicitSigned>("ExplicitSigned");
  printInfosAboutT<ExplicitUnsigned>("ExplicitUnsigned");
}

--=20
You are receiving this mail because:
You are on the CC list for the bug.=