overflows in SLDivNode

[Raffaello Giulietti]

Hi Andreas,

yes, I just posted a comment on the idiv instruction a couple of minutes 
ago ;-)

OK, the important point is that SL behaves correctly, since its 
structure will be surely copied by other Truffle language 
implementations, including the division AST node.





On 2015-04-27 16:17, Andreas Woess wrote:
> Thanks for pointing out the bug, Raffaello. We'll fix SL.
> However, I don't think we should add a divExact method. We cannot
> intrinsify it (the idiv instruction does not set the overflow flag); for
> the same reason Java 8 does not have a divideExact. Also, the utility
> method cannot specialize (whereas the SLDivNode can), so having it does
> not buy us anything.
>
> - andreas
>
> On 27/04/15 15:26, christian.humer at gmail.com wrote:
>> Hi Raffaello,
>>
>> Thanks for pointing this out.
>>
>> I am a little unsure how to name the divExact method in ExactMath. The
>> term "exact" might be misleading here as it actually rounds towards 0
>> without throwing the exception. What if we want to add a divExact that
>> throws if the result looses information? I am open to suggestions.
>> Will push a fix just for SL in the meantime.
>>
>> - Christian Humer
>>
>>
>>
>>
>> ------ Original Message ------
>> From: "Raffaello Giulietti" <raffaello.giulietti at supsi.ch>
>> To: graal-dev at openjdk.java.net
>> Sent: 27.04.2015 14:17:53
>> Subject: Re: overflows in SLDivNode
>>
>>> The following method (and the equivalent for int) might be added to
>>> ExactMath to help implementing the division correctly.
>>>
>>>
>>>     public static long divExact(long x, long y) {
>>>         long r = x / y;
>>>         if ((x & y & r) < 0) {
>>>             throw new ArithmeticException("long overflow");
>>>         }
>>>         return r;
>>>     }
>>>
>>>
>>> Since SL is meant to be an exemplary Truffle language, I feel it will
>>> be surely imitated, so it is important to keep it as correct as
>>> possible.
>>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>>
>>>
>>>
>>> On 2015-04-26 17:51, Raffaello Giulietti wrote:
>>>> Hi,
>>>>
>>>> I'm just studying the SL implementation in the last Graal/Truffle
>>>> update.
>>>>
>>>> The long specialization of the division wrongly assumes that
>>>> /* No overflow is possible on a division. */
>>>>
>>>> When left is Long.MIN_VALUE and right is -1 the division overflows.
>>>>
>>>> OK, OK, OK, this is the only case and has a ridiculous
>>>> (cryptography-like) probability of 2^-128 to happen randomly. And, no,
>>>> neither java.lang.Math nor ExactMath cover this rare case of overflow.
>>>>
>>>> Greetings
>>>> Raffaello
>>>
>>
>