> On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> > Tried this patch and I ran into some issues, some variables are using
> > unsigned char to hold machine mode and will have problems when the
> > number of modes is larger than 255...
> >
> > And here is the fix:
>
> > --- a/gcc/genmodes.cc
> > +++ b/gcc/genmodes.cc
> > @@ -1141,10 +1141,10 @@ inline __attribute__((__always_inline__))\n\
> > #else\n\
> > extern __inline__ __attribute__((__always_inline__, __gnu_inline__))\n\
> > #endif\n\
> > -unsigned char\n\
> > +unsigned short\n\
> > mode_inner_inline (machine_mode mode)\n\
> > {\n\
> > - extern const unsigned char mode_inner[NUM_MACHINE_MODES];\n\
> > + extern const unsigned short mode_inner[NUM_MACHINE_MODES];\n\
> > gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
> > switch (mode)\n\
> > {");
> > @@ -1529,7 +1529,7 @@ emit_mode_wider (void)
> > int c;
> > struct mode_data *m;
> >
> > - print_decl ("unsigned char", "mode_next", "NUM_MACHINE_MODES");
> > + print_decl ("unsigned short", "mode_next", "NUM_MACHINE_MODES");
>
> Etc.
>
> Instead of 's%char%short', shouldn't we really be using
> 'enum machine_mode' here? (I understand such a change may require some
> further surgery, but wouldn't it be the correct thing to do?)
Hmmm, I think maybe what we need is to leverage C++ language features
to declare enum with underlying types like that:
enum machine_mode : uint16_t
