Re: Questions about a patch fixing bug #61414

["Sam van Kampen via gcc" <gcc at gcc dot gnu dot org>]

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