overflows in SLDivNode

[Raffaello Giulietti]

Hi Christian,

I agree that the name is not the most favorable: it's more a mechanical 
result of "copy'n'paste" from the other names in ExactMath than a 
conscious choice.

In the meantime I took a look at the x86_64 instruction set. In case of 
an overflow, the idiv instruction raises an exception rather than 
setting a flag, so I'm not sure how an optimized compiler intrinsic 
could look. It would probably look differently than the addExact() case.

Thanks for the fix.
Raffaello



On 2015-04-27 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
>>
>