Re: New no-undefined-overflow branch

[Paolo Bonzini <bonzini at gnu dot org>]

Eus wrote:
> Hi Ho!
> 
> On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
>>> So while trapping variants can certainly be introduced it looks like
>>> this task may be more difficult.
>> I don't think you need to introduce trapping tree codes.  You can
>> introduce them directly in the front-end as
>>
>>    s = x +nv y
>>    (((s ^ x) & (s ^ y)) < 0) ? trap () : s
> 
> Could you please kindly explain a bit about it?
> 
> Suppose s, x, and y are 8-bit signed integer.
> If x and y are -128, s = (-128) + (-128), which will overflow.
> Now if suppose s is 0, ((0 ^ -128) & (0 ^ -128)) == -128, which is less
> than zero and will trap. This is correct.
> But, if s is -128, ((-128 ^ -128) & (-128 ^ -128)) is zero and will not
> trap. This is incorrect, isn't this?

Don't look at it as an arithmetic test, "< 0" is just a shortcut for
"the most significant bit of the first operand is 1".  So the formula's
outcome only depends on the ANDs and XORs of the sign bits; it means,
"trap if the result's sign is different from both addends' signs" or
equivalently "check that the result's sign matches at least one addend's
sign".

You can also say "((s ^ x) & ~(x ^ y)) < 0", or equivalently "((s ^ y) &
~(x ^ y)) < 0".  These mean "trap if the two addends have the same sign
and the sum has a different sign".  It is easy to prove that they are
equivalent:

  s    x    y     s^x    s^y     ~(x^y)      equal?
  0    0    0      0      0         1          yes (0)
  0    0    1      0      1         0          yes (0)
  0    1    0      1      0         0          yes (0)
  0    1    1      1      1         1          yes (1)
  1    0    0      1      1         1          yes (1)
  1    0    1      1      0         0          yes (0)
  1    1    0      0      1         0          yes (0)
  1    1    1      0      0         1          yes (0)

Paolo