[Bug gdb/31331] Wenum-constexpr-conversion should be fixed, soon treated as a hard error

["carlosgalvezp at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #3 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
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 = cond ? enum_1 : enum_2;

Does not make much sense. If these were C++ enums, the code would not compile.
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, it'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 the
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 read in
the wiki that there are failing tests on trunk, so one needs to diff the test
logs. Diffing the test logs is only possible if they have the same content in
the same order?

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