Re: [PATCH] fix typing error in compound assignment

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Sat, Dec 10, 2016 at 02:14:00AM +0000, Al Viro wrote:
> On Wed, Dec 07, 2016 at 03:33:42PM +0100, Luc Van Oostenryck wrote:
> > But what is really done currently is something like:
> > 	x = x + (typeof(x)) a;
> > In other words, the left-hand side is casted to the same type as the
> > rhs and the operation is always done with this type, neglecting the
> > usual conversions and thus forcing the operation to always be done
> > with the rhs type, here 'int' instead of 'long'.
> 
> Addition is a bad example, actually - your variant (promotions + operaton +
> cast down to the first argument due to assignment) will yield the same value.
> It's division where the real trouble happens -
> 	unsigned n1 = 1, n2 = 1;
> 	long v = -1;
> 	n1 /= v;
> 	n2 /= (unsigned)v;
> 
> should yield n1 == ~0U, n2 == 0.  And yes, the current logics in sparse
> does not distinguish between those.  So ACK on the fix, but you want
> a better testcase.

Absolutely. In fact, I found the problem when a was a double and
I saw that the addition was still done with a 32bit wide operation.
I used this example because there is too much problems with floating-point
operations.
I'll reuse your example, which is more 'dramatic' that mine.

Thanks for the review.