Consider this source: enum class K : unsigned int { V = 27 }; struct S { K v : 5; }; When I compile this with Fedora 20 g++ (4.8.2-based) I get: barimba. g++ --syntax-only -pedantic -std=c++11 /tmp/q.cc /tmp/q.cc:6:9: warning: ‘S::v’ is too small to hold all values of ‘enum class K’ [enabled by default] K v : 5; ^ However, 5 bits is sufficient to hold all the values of K. The warning goes away if I increase the size to 32, though of course that defeats the purpose.
Jonathan pointed out that this is not really a bug because an enumeration with a fixed underlying type has a different definition of its underlying values. However, the bug still exists if the underlying type is not fixed: enum class K { V = 27 }; struct S { K v : 6; }; barimba. g++ --syntax-only -pedantic -std=c++11 /tmp/q.cc /tmp/q.cc:6:9: warning: ‘S::v’ is too small to hold all values of ‘enum class K’ [enabled by default] K v : 6; ^
(In reply to Tom Tromey from comment #1) > However, the bug still exists if the underlying type is not fixed: > > enum class K { > V = 27 > }; This enum K also has a fixed underlying type (int). Contrary to unscoped enums, *all* scoped enums have a pre-defined underlying type that does not depend on the individual enumerators.
(In reply to Daniel Krügler from comment #2) > (In reply to Tom Tromey from comment #1) > > However, the bug still exists if the underlying type is not fixed: > > > > enum class K { > > V = 27 > > }; > > This enum K also has a fixed underlying type (int). Contrary to unscoped > enums, *all* scoped enums have a pre-defined underlying type that does not > depend on the individual enumerators. Hah, shows what I know. Regardless, this warning does not seem to be useful to me.
I think that this warning is not on right place. for example if I use bitfield: struct S { unsigned int v : 5; }; then this works without any warn, so why I can't use enum class typed to unsigned int?
It seems G++ always throw that warning for enum class as bitfield, even when the enum class is actually empty: > enum class K {}; > struct S { > K v : 5; > }; G++ would give: > test.cpp:3:9: warning: 'S::v' is too small to hold all values of 'enum class K' > K v : 5;
(In reply to Xidorn Quan from comment #5) > It seems G++ always throw that warning for enum class as bitfield, even when > the enum class is actually empty: > > enum class K {}; > > struct S { > > K v : 5; > > }; > > G++ would give: > > test.cpp:3:9: warning: 'S::v' is too small to hold all values of 'enum class K' > > K v : 5; Yes, read comment 2.
PR 51242 discusses the same issue, and PR 51242 comment 27 notes that Clang only warns when a value that isn't known to fit is assigned to the bitfield, which seems more useful. At the very least there should be a -Wxxx switch controlling this option so it can be disabled.
Definitely a plus one to a switch to disable the warning: we currently have to work around this by putting code that does this in an -Isystem directory!
This does not seem like correct behavior to me either. The warning should be based on the maximum declared enum value, not the maximum possible value held by the underlying type. After all as of C++17, the standard makes it undefined what happens if you try to stuff an integer into an enum value that doesn't correspond to one of the values listed in the enum declaration.
I ran into this again, went to file a bug, and then found that I'd already filed the bug...
Present in 5.4 through 7.2 at least.
(In reply to eric-bugs from comment #9) > This does not seem like correct behavior to me either. The warning should be > based on the maximum declared enum value, not the maximum possible value > held by the underlying type. No. > After all as of C++17, the standard makes it undefined what happens if you > try to stuff an integer into an enum value that doesn't correspond to one of > the values listed in the enum declaration. What? No it doesn't.
I've sent a patch that adds the warning flag -Wbitfield-enum-conversion to gcc-patches, and the gcc mailing list now also has a thread on the bug, and I thought I might share them on the bug tracker: The patch: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00989.html The thread on the bug: https://gcc.gnu.org/ml/gcc/2017-10/msg00121.html
(In reply to Jonathan Wakely from comment #7) > At the very least there should be a -Wxxx switch controlling this option so > it can be disabled. Agreed, that falls under bug 44209; retitling this one accordingly. (In reply to Sam van Kampen from comment #13) > I've sent a patch that adds the warning flag -Wbitfield-enum-conversion to > gcc-patches, and the gcc mailing list now also has a thread on the bug, and > I thought I might share them on the bug tracker: > > The patch: > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00989.html > > The thread on the bug: > https://gcc.gnu.org/ml/gcc/2017-10/msg00121.html The name chosen for the flag makes it sound kinda related to bug 39170 but I guess the "enum" in the middle is enough of a differentiator.
hi, Just a ping for this issue. Since it's about declarations and it is not possible to disable it, as soon as you have headers files using the feature you get flooded with thousands of warnings making it impossible to see the other actually useful warnings...
Sam, did you get a chance to implement the changes requested on the mailing list?
Hi, it's me, another programmer who would love to use enum classes in bitfields instead of having to static_cast back and forth :-) Can anybody fixup Sam's patch?