/* This is another case of narrowing, specifically when there's an outer
    BIT_AND_EXPR which masks off bits outside the type of the innermost
    operands.   Like the previous case we have to convert the operands
    to unsigned types to avoid introducing undefined behaviour for the
    arithmetic operation.  */


Essentially tthat pattern in match.pd is trying to catch cases where we 
widen two operands, do some arithmetic, then mask off all the bits that 
were outside the width of the original operands.

In this case the mask is -2 and the inner operands are unsigned 
characters that get widened to signed integers.

Obviously with a mask of -2, the we are _not_ masking off bits outside 
the width of the original operands.  So even if those operands are 
marked with TYPE_OVERFLOW_WRAPS, this optimization must not be applied.

What's so obviously missing here is actually checking the mask.

(mask & (-1UL << TYPE_PRECISION (original operand))) == 0

Is a nice simple way to know if there's any bits outside the precision 
of the original operand  in the mask.

Bootstrapped and regression tested on x86_64-linux-gnu.  OK for the trunk?

Thanks,
jeff