From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0F82C385783F; Tue, 13 Feb 2024 23:54:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0F82C385783F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1707868462; bh=QdJRpLQaCR6jb6QPEpk9BeNNK/ELD5KoJelsNzd2VJs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IAELwJN/WMx8FkCh1zvNbkfciLEdGPzjLzI4KNpkMQcDoBXSdnDDRcdiWaLmZI5zF bLaxRrnidUflWxgRSNl/PmDJ2K7i0EuQUjgeZ2l6OgHBxVfMH3Cin6EuJaH41oTbs6 jIIHIF8LQhsGEduR+aiPycs7I53CRgGCZstOtU1A= From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/31331] Wenum-constexpr-conversion should be fixed, soon treated as a hard error Date: Tue, 13 Feb 2024 23:54:20 +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: tromey at sourceware dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 15.1 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31331 --- Comment #30 from Tom Tromey --- IIUC the current state is: - there's no way to detect whether an enum has an explicit underlying type - we can't use the current approach to detecting if the underlying type is signed - we can't force an underlying type to be unsigned because it would break the compile plugin ABI - but we can't rely on the underlying type of C-like enums to be unsigned since that is compiler dependent - we can't use the promotion detection since that is too broad It seems to me that there's no need to support a signed enumeration constant in enum-flags. It just isn't useful. So, could all the work be done in an unsigned type that is big enough, and then if the enum is signed, mask off the high bit (and assert that no constant with the high bit set is ever passed in)? For enums with a signed underlying type this would mean sacrificing one flag value. But that seems ok. For unsigned enums it would all stay the same. operator~ could just be defined unconditionally. --=20 You are receiving this mail because: You are on the CC list for the bug.=