[PATCH] 4511638: Double.toString(double) sometimes produces incorrect results
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 .
>>> In the next days, my sponsor Brian Burkhalter will publish it as a
>> 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:
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
g = g1 2^64 + g0
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
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
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