[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[db0451 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #18 from DB <db0451 at gmail dot com> ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to DB from comment #12)
> > (In reply to Jonathan Wakely from comment #11)
> > > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> > > -fstrict-enums tells the compiler it will never have a value outside that
> > > range. It does **not** tell it that the type will never have the value 0 or
> > > 2.
> > 
> > Huh. So allows non-named values and only enforces min/max, so doesn't
> > account for folk doing bitwise ORing?
> 
> Huh? I have no idea what you mean by doesn't account for bitwide ORing. The
> fact you can have non-named values is essential for bitwide ORing.
> 
> enum Bitmask { bit1 = 1, bit2 = 2, bit4 = 4 };
> Bitmask b = Bitmask(bit1|bit4);
> 
> This creates a value that doesn't correspond to a named enumerator, but
> obviously this is valid. (For this type the values of the type are [0,7]
> because 7 is the highest value that can be represented in the minimum number
> of bits needed to represent all the enumerators).


My doubt ultimately arose from a momentary fail at bitwise arithmetic (thinking
1 | 3 == 4, how embarrassing), but I'm glad it elicited this confirmation!
Thanks.