On Sat, Oct 14, 2017 at 04:43:33PM +0100, Jonathan Wakely wrote:
> On 14 October 2017 at 15:50, Sam van Kampen wrote:
> > Dear maintainers,
> >
> > Having come across https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
> > (bug #61414) quite often myself I decided I wanted to fix it.
> >
> > By reading through parts of the GCC internals manual I have
> > managed to add a warning flag, the code for which I will submit to
> > gcc-patches, but since this is my first time contributing to GCC I have
> > some questions.
> >
> > 1. When it comes to the patch, should I post it to the bug tracker
> > before sending it to gcc-patches?
>
> No. Patches go to the mailing list, not bugzilla.
>
> But you can add the URL of the gcc-patches mail to bugzilla (and then
> somebody should add the "patch" keyword to the bug).
Noted.
> > 2. A better fix for this bug would be to only warn when the number
> > of defined enumerators would not fit inside a bitfield of the
> > specified size. Seeing as I don't know the GCC internals very
> > well, I'm wondering if anyone could point me in the right
> > direction when it comes to getting the number of defined
> > enumerators in an enum type.
>
> Why does the number of enumerators make any difference?
I suppose the number of enumerators does not make any difference, but
rather the enumerator with the highest integer value. For instance, in
this example:
enum class A { A, B, C; };
struct D { A enum_field : 2; };
the enumerator with the highest integer value is C, with an integer
value of 2. This enum type therefore fits inside the bit-field in
struct D, and so the compiler should not emit a warning in my eyes.
Of course, you can cast an integer to an enum type and assign it that
way, which should probably trigger a warning if the value could be too
large (it already triggers -Woverflow if the value is a compile-time
constant).
> > 3. When it comes to documentation and tests, I've documented the
> > flag in doc/invoke.texi and will add a test in the test suite,
> > hopefully when the patch includes the check specified in 2. Are
> > there are any other places I should add documentation?
>
> No, that's all.
Thanks.
Sam
