http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
Martin Sebor <msebor at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gmail dot com
--- Comment #2 from Martin Sebor <msebor at gmail dot com> 2011-06-09 23:03:38
UTC ---
I think this is a bug since there can be no overflow (or slicing) here. Here's
my reasoning.
According to 6.5.16.2 Compound assignment of C99:
A compound assignment of the form E1 op= E2 differs from the simple
assignment
expression E1 = E1 op (E2) only in that the lvalue E1 is evaluated only once.
and 6.5.16.1 Simple assignment:
In simple assignment (=), the value of the right operand is converted to the
type of the assignment expression and replaces the value stored in the object
designated by the left operand.
and finally 6.5.16 Assignment operators:
The type of an assignment expression is the type of the left operand...
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.
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).
