On 25/04/2020 22:50, Segher Boessenkool wrote: > Hi! > > On Sat, Apr 25, 2020 at 02:20:19AM +0200, Iain Buclaw via Gcc-patches wrote: >> + // Parse DoubleDoubles as a pair of doubles. >> + // The layout of the type is: >> + // >> + // [1| 7 | 56 ][ 8 | 56 ] >> + // [S| Exp | Fraction (hi) ][ Unused | Fraction (low) ] >> + // >> + // We can get the least significant bits by subtracting the IEEE >> + // double precision portion from the real value. > > That's not correct. There is no "Unused" field, and the lower fraction > is not always an immediate extension of the higher fraction. > > (It's not 1,7,56 -- it is 1,11,52). >
Thanks, I did a quick look-up of where the original might have came from, and I've found another extended floating point format of IBM. I'll send the correction upstream. > A "double double" is really a pair of double precision numbers, both > with sign and exponent fields. If the first number has maximum > exponent (so, it is infinity or a NaN), the second number is not > significant; otherwise, the sum of the two numbers (taken as exact > numbers, no rounding, no truncation, etc.) is the represented number. > The first number should be that, rounded to double precision. > > So the second double does "add fraction bits" somewhat like this, but > there is an implicit leading 1, for normal numbers, and there can be a > gap between the two halves, too (like in 0x1p0 + 0x1p-100). > > The job of this routine is to pry out the byte representation of real (long double) values at compile-time for hashing-related purposes. As zero, infinity and NaN are already handled, unless a mismatch between compile and run-time computed hashes is found (I haven't seen any unit-tests trigger failures in the testsuite), I don't think that there is any immediate problem with the current implementation. Thanks for the information though. Iain.
