From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B0D2C385840F; Sun, 4 Feb 2024 18:10:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0D2C385840F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1707070215; bh=ekk/IHCj0c1Hebs8TrWMgkWXiCdCvCn48K5DYbmdexw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AQfWP1sB2BMEtBAerxt+kre9Hhjuz5LcVKptXXi9okNXVwWj0oYzXi0r6Hsina0Bo OggKfBd3VVL28ixpgvfIT3Ky7QoFoPgBzkTjyQ5ihZSJhVD5YSwrwmepj514K32JJY q7199HedavEPDin29ZlP+3kvRCs+fwrmA99guHw8= From: "carlosgalvezp at gmail dot com" 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:10:14 +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: carlosgalvezp at gmail dot com 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: 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 #3 from Carlos Galvez --- Exactly, I really don't understand the purpose of that part of test - what requirement from the production code is it enforcing/protecting? I see a couple issues with the existing code: - The assumption that C-style enums are signed. This is not true - it's implementation-defined behavior, and one should typically not rely on that.= In practice, we observe that if a C-style enum has all values positive, the underlying type is unsigned, otherwise signed. - As you point out, the expression: auto var =3D cond ? enum_1 : enum_2; Does not make much sense. If these were C++ enums, the code would not compi= le. One should either use a std::variant, or explicitly cast the enums to int. I would thus vote for removing that part from the test (as you mentioned, i= t's marked as unimportant). But it would be good to understand why it was added= in the first place. I'm also unsure if we can trust that everything still works just because it compiles fine (maybe some implicit conversions leading to t= he wrong numbers). I was considering to fiddle with it and run "make check" but I had a couple= of questions: - How long time is it expected to take, on say 16 cores? - Will the output log be deterministic even when running in parallel? I rea= d in the wiki that there are failing tests on trunk, so one needs to diff the te= st logs. Diffing the test logs is only possible if they have the same content = in the same order? --=20 You are receiving this mail because: You are on the CC list for the bug.=