[PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Raffaello Giulietti raffaello.giulietti at gmail.com
Thu Mar 7 19:16:58 UTC 2019

On 2019-03-07 11:10, Brian Burkhalter wrote:
>> On Mar 7, 2019, at 10:04 AM, Andrew Haley <aph at redhat.com 
>> <mailto:aph at redhat.com>> wrote:
>> On 3/6/19 7:31 PM,raffaello.giulietti at gmail.com 
>> <mailto:raffaello.giulietti at gmail.com>wrote:
>>> the latest version of the patch, replacing the one found at [1].
>>> In the next days, my sponsor Brian Burkhalter will publish it as a 
>>> webrev.
>> I still believe you'd be better off defining an unsigned multiplyHigh than
>> all that messing about with shifts and masks in rop().
> There is in fact an open issue for unsigned multiplyHigh:
> https://bugs.openjdk.java.net/browse/JDK-8188044
> Brian

Hi Andrew,

a couple of weeks ago I tried to refactor the code assuming the 
existence of unsignedMultiplyHigh() (either as some future intrinsic or 
as a Java method) and a wider representations of g with either 127 or 
128 bits:
     g = g1 2^64 + g0

with either
     2^63 <= g1 < 2^64 (128 bits)

     2^62 <= g1 < 2^63 (127 bits)

Unfortunately, the resulting code of rop() isn't any simpler. That's 
because then an intermediate sum can overflow the 64 bits of a long. As 
a consequence, there's need for more elaborate logic to determine
the carry and other slightly more complicated computations to assemble
the final result. All in all, the resulting code has more operations and 
looks longer.

I tried with four variants. In addition to the mults, which are needed 
anyway, the current code has 3 shifts, 3 adds, 2 bitwise logicals. As 
mentioned, I couldn't come up with a solution that would help reducing 
this count.

I would be glad to hear of better solutions and to write down a 
mathematical proof for the document.

In the meantime I got rid of the last division. There's no division at 
all in the whole algorithm.


More information about the core-libs-dev mailing list