ARM testers, make note.
Iain Buclaw
ibuclaw at ubuntu.com
Tue Aug 20 02:57:02 PDT 2013
On 20 August 2013 10:07, Johannes Pfau <nospam at example.com> wrote:
> Am Fri, 16 Aug 2013 18:33:14 +0200
> schrieb "Iain Buclaw" <ibuclaw at ubuntu.com>:
>
>> I've pushed in pure implementations of functions in std.math,
>> removing the workaround in core.stdc.math.
>>
>> This passes for x64/x32. Can any ARM testers please report any
>> problems causecd by this update?
>>
>> Thanks
>> Iain.
>
> I found a bug in the floor implementation for 64 bit reals:
>
> int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
> The constants are wrong: At least 0x7ff must be 0x7ff0.
>
> (Remember, the 16 bits are s|eeeeeeeeeee|???? )
>
> However, the results are still wrong and I don't really understand how
> that equation should work.
>
> The 'naive' and working way to write this is
> --------
> int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
> --------
>
> I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then
> the result is still left-shifted by 4 and needs to be right-shifted:
> -------
> int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
> -------
>
> is also working, but I don't know what's the advantage of this version.
>
> floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?
>
>
Thanks, it should be:
---
int exp = ((vu[F.EXPPOS_SHORT] >> 4) & 0x7ff) - 0x3ff;
I'll raise a pull to fix as my pull into phobos got merged this morning. :o)
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
More information about the D.gnu
mailing list