Fair enough, I didn't know whether to change the way it currently was
triggered. Do you think it should fall under -Wextra (I don't think it
falls under -Wall, since it isn't "easy to avoid or modify to prevent
the warning" because it may be valid and wanted behavior), or should it
be enabled by no other flag?
I think it depends on the implementation of the warning. With
the current (fairly restrictive) behavior I'd say it should be
disabled by default. But if it were to be changed to more closely
match the Clang behavior and only warn for bit-field declarations
that cannot represent all enumerators of the enumerated type, then
including it in -Wall would seem helpful to me.
I.e., Clang doesn't warn on this and IIUC that's what the reporter
of the bug also expects:
enum E: unsigned { E3 = 15 };
struct S { E i: 4; };
(There is value in warning on this as well, but I think most users
will not be interested in it, so making the warning a two-level one
where level 1 warns same as Clang and level 2 same as GCC does now
might give us the best of both worlds).
The warning points to the bit-field ('field:2' is too small to hold...),
but I've added a note in an updated patch that tells the user what the
precision of the enum's underlying type is.
That will be useful, thanks!
I've changed the description in both c.opt and invoke.texi to be more
specific, it now notes that it warns when
1. An enum in a bit-field is a scoped enum...
2. ...which has an underlying type which has a higher precision
than the width of the bit-field.
Sounds good.
Martin
