On Sun, Apr 26, 2020 at 10:38:57AM +0200, Iain Buclaw wrote: > On 25/04/2020 22:50, Segher Boessenkool wrote: > > 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.
All bits are significant to the value, there are no unused bits, for most values. The sign and exponent of the second number are very much relevant, in general. I didn't look at your actual implementation, just this comment, but it sounds like your tests miss a lot of cases, if no problems were found? Segher
