[Bug c/41138] Inconsistent (incorrect?) "overflow in implicit constant conversion" warning

["vincent-gcc at vinc17 dot net" <gcc-bugzilla at gcc dot gnu dot org>]

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

Vincent LefÃvre <vincent-gcc at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent-gcc at vinc17 dot net

--- Comment #5 from Vincent LefÃvre <vincent-gcc at vinc17 dot net> ---
(In reply to Martin Sebor from comment #2)
> So all cases are equivalent to
> 
>   foo = foo & 65280;
> 
> The result of the expression (foo & 65280) is an int (or unsigned int, long,
> unsigned long, depending on the suffix of the constant) which is converted
> to char (the type of the assignment expression). In all cases in the first
> test case, the value of the result is guaranteed to be representable in
> unsigned char. There is no overflow or slicing and the code is strictly
> conforming with safe semantics.

I don't think that the code is strictly conforming: if foo == 0, the result is
implementation-defined because a signed 0 may have two possible representations
if the integer representation is not two's complement. However, I doubt that
the warning is related to that, because this is not related to overflow.

> That said, a warning stating that foo &= 65280 always evaluates to zero
> might be useful in case the intent wasn't to clear the variable (otherwise
> the code could be rewritten as foo = 0).

There shouldn't be a warning by default for the case the result is always 0:
the value 65280 could come from a macro whose value depends on the build
context. This is the same thing with always true or always false comparisons
(one used to get a warning in the past, but this has been fixed, AFAIK).