overflows in SLDivNode

Andreas Woess andreas.woess at oracle.com
Mon Apr 27 14:17:43 UTC 2015


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
>>
>



More information about the graal-dev mailing list