| Submitter | Paolo Carlini |
|---|---|
| Date | Nov. 26, 2012, 3:42 p.m. |
| Message ID | <50B38DEC.8090004@oracle.com> |
| Download | mbox | patch |
| Permalink | /patch/201712/ |
| State | New |
| Headers | show |
Comments
The patch is OK. To deal with the warning, I would suggest putting the constrained type somewhere other than ENUM_UNDERLYING_TYPE that's shared between enums with fixed and non-fixed underlying types; having it in ENUM_UNDERLYING_TYPE isn't really correct anyway. Jason
Patch
Index: decl2.c =================================================================== --- decl2.c (revision 193814) +++ decl2.c (working copy) @@ -1030,7 +1030,7 @@ grokbitfield (const cp_declarator *declarator, if (TREE_CODE (value) == VOID_TYPE) return void_type_node; - if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (value)) + if (!INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (value)) && (POINTER_TYPE_P (value) || !dependent_type_p (TREE_TYPE (value)))) {
Hi, this PR is about the rejection (in C++11 mode of course) of: enum class MyEnum { A = 1 }; struct MyClass { MyEnum Field1 : 3; }; whereas the corresponding unscoped enum case already works. As noticed by Jon, it seems that the below straightforward patchlet is enough to solve the problem but then we have a warning issue: 51242.C:5:19: warning: ‘MyClass::Field1’ is too small to hold all values of ‘enum class MyEnum’ [enabled by default] which is easily explained: the underlying type is fixed (to an implicit int type), thus in finish_enum_value_list, fixed_underlying_type_p is true and the code "restricting" the ENUM_UNDERLYING_TYPE for diagnostic purposes doesn't run. In other terms, we warn for the same reason we for example -Wnarrowing warn (before erroring out) for: enum class Code { SUCCESS = 0 }; Code a; short r[] = {a}; That seems intended, but especially annoying in the bitfield case. An idea could be giving a name to the "too small to hold all values" warning and making possible disabling it. What do you suggest? Thanks! Paolo.