D.gnu - ARM testers, make note.

Iain Buclaw (6/6) Aug 16 2013 I've pushed in pure implementations of functions in std.math,

Iain Buclaw (3/9) Aug 16 2013 Commit reference:

Johannes Pfau (8/21) Aug 18 2013 Compiling phobos fails with this message:

Iain Buclaw (7/28) Aug 18 2013 OK, fixed that:
Iain Buclaw (7/37) Aug 18 2013 Made the tiniest amendment:

Johannes Pfau (19/27) Aug 20 2013 I found a bug in the floor implementation for 64 bit reals:

Iain Buclaw (8/35) Aug 20 2013 Thanks, it should be:
Iain Buclaw (5/48) Aug 20 2013 Pull: http://j.mp/171CJl7

Johannes Pfau (56/64) Aug 22 2013 I did a complete pass through the std.math unit tests. As soon as these

Iain Buclaw (8/72) Aug 22 2013 Make Don aware of this. But looks ok to me. Does it fail in the same

Johannes Pfau (8/11) Aug 23 2013 If I modify frexp to use double instead of real it also fails on

Johannes Pfau (12/17) Aug 23 2013 Do you have any uncommitted changes for std.math? There's one remaining

Iain Buclaw (6/23) Aug 23 2013 Weird, I've never noticed this when running on 32bit/64bit test

"Iain Buclaw" <ibuclaw ubuntu.com> writes:

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.

Aug 16 2013

"Iain Buclaw" <ibuclaw ubuntu.com> writes:

On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
 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.

Commit reference:
https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395

Aug 16 2013

Johannes Pfau <nospam example.com> writes:

Am Fri, 16 Aug 2013 18:38:08 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
 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.

 
 Commit reference:
 https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395
 

Compiling phobos fails with this message:

../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static
assert  "Only 80-bit and 96-bit reals are supported by lrint()"

real is 64 bit on most (all?) ARM machines.


I also started the compiler test suite some time ago but it will take
some more time till it's finished.

Aug 18 2013

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 18 August 2013 09:54, Johannes Pfau <nospam example.com> wrote:
 Am Fri, 16 Aug 2013 18:38:08 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
 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.

 Commit reference:
 https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395

 Compiling phobos fails with this message:

 ../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static
 assert  "Only 80-bit and 96-bit reals are supported by lrint()"

 real is 64 bit on most (all?) ARM machines.


 I also started the compiler test suite some time ago but it will take
 some more time till it's finished.


OK, fixed that:
https://github.com/D-Programming-GDC/GDC/commit/196fdf37b3b3e7d25b09a1cac1f30e313274e6e5

:o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Aug 18 2013

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 18 August 2013 15:27, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 18 August 2013 09:54, Johannes Pfau <nospam example.com> wrote:
 Am Fri, 16 Aug 2013 18:38:08 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
 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.

 Commit reference:
 https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395

 Compiling phobos fails with this message:

 ../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static
 assert  "Only 80-bit and 96-bit reals are supported by lrint()"

 real is 64 bit on most (all?) ARM machines.


 I also started the compiler test suite some time ago but it will take
 some more time till it's finished.


 OK, fixed that:
 https://github.com/D-Programming-GDC/GDC/commit/196fdf37b3b3e7d25b09a1cac1f30e313274e6e5

Made the tiniest amendment:
https://github.com/D-Programming-GDC/GDC/commit/05b6e48d5d7736c7bcaeff9d71c807bcd0132dca


Should be all good after some preliminary testing vs __builtin_lrintl() results.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Aug 18 2013

Johannes Pfau <nospam example.com> writes:

Am Fri, 16 Aug 2013 18:33:14 +0200
schrieb "Iain Buclaw" <ibuclaw 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?

Aug 20 2013

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 20 August 2013 10:07, Johannes Pfau <nospam example.com> wrote:
 Am Fri, 16 Aug 2013 18:33:14 +0200
 schrieb "Iain Buclaw" <ibuclaw 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';

Aug 20 2013

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 20 August 2013 10:57, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 20 August 2013 10:07, Johannes Pfau <nospam example.com> wrote:
 Am Fri, 16 Aug 2013 18:33:14 +0200
 schrieb "Iain Buclaw" <ibuclaw 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)

Pull:  http://j.mp/171CJl7



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Aug 20 2013

Johannes Pfau <nospam example.com> writes:

Am Fri, 16 Aug 2013 18:33:14 +0200
schrieb "Iain Buclaw" <ibuclaw 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 did a complete pass through the std.math unit tests. As soon as these
issues are addressed, std.math unit tests should succeed on ARM: 

Some more small bugs:
(see also
https://github.com/jpf91/GDC/commit/63890f543f60d55bad3dc6bced4d14bc159128e6
)

==========================
In isInfinity we should check for 11 binary '1's, not 12 right?

        return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
            == 0x7FF8_0000_0000_0000;

=>

        return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
            == 0x7FF0_0000_0000_0000;
==========================
In frexp:

vu[F.EXPPOS_SHORT] = cast(ushort)((0x8000 & vu[F.EXPPOS_SHORT]) |
0x3FE0);

=>

vu[F.EXPPOS_SHORT] = cast(ushort)((0x800F & vu[F.EXPPOS_SHORT]) |
0x3FE0);
==========================
Why is ex in frexp unsigned? This line fails because of this:
exp = (ex - 0x3FE0) >> 4;
here ex is always zero so the subtraction doesn't work as ex is
unsigned
==========================




Failing unit tests:
(see also
https://github.com/jpf91/GDC/commit/0d7b3feafdb3629aeccb44b2a28d3344c7675d2f
)
==========================
assert(exp2(0.5L)== SQRT2); //Only 52 mantissa bits are equal
==========================
real n = frexp(0x1p-16384L, x); //value is too small to fit in double
==========================

real y = vals[i][1];
real z = vals[i][2];
real h = hypot(x, y);
For some values only 52 mantissa bits are equal
==========================
assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
//Only 52 mantissa bits are equal
==========================
assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
Fails in exactly the same way on dpaste:
http://dpaste.dzfl.pl/4c794ab8
==========================
assert(pow(x, neg3) == 1 / (x * x * x));
//Only 52 mantissa bits are equal
==========================
assert(feqrel(real.min_normal / 8, real.min_normal / 17) == 3);
//feqrel returns spectacular -732 equal bits. But it's the same on x86
//with double so it's a bug in the test case. I can't fix it as I
//don't know what it's supposed to do

Aug 22 2013

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 22 August 2013 20:45, Johannes Pfau <nospam example.com> wrote:
 Am Fri, 16 Aug 2013 18:33:14 +0200
 schrieb "Iain Buclaw" <ibuclaw 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 did a complete pass through the std.math unit tests. As soon as these
 issues are addressed, std.math unit tests should succeed on ARM:

 Some more small bugs:
 (see also
 https://github.com/jpf91/GDC/commit/63890f543f60d55bad3dc6bced4d14bc159128e6
 )

 ==========================
 In isInfinity we should check for 11 binary '1's, not 12 right?

         return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
             == 0x7FF8_0000_0000_0000;

 =>

         return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
             == 0x7FF0_0000_0000_0000;
 ==========================
 In frexp:

 vu[F.EXPPOS_SHORT] = cast(ushort)((0x8000 & vu[F.EXPPOS_SHORT]) |
 0x3FE0);

 =>

 vu[F.EXPPOS_SHORT] = cast(ushort)((0x800F & vu[F.EXPPOS_SHORT]) |
 0x3FE0);
 ==========================
 Why is ex in frexp unsigned? This line fails because of this:
 exp = (ex - 0x3FE0) >> 4;
 here ex is always zero so the subtraction doesn't work as ex is
 unsigned
 ==========================

Make Don aware of this. But looks ok to me.  Does it fail in the same
way for double on x86/x86_64?


 Failing unit tests:
 (see also
 https://github.com/jpf91/GDC/commit/0d7b3feafdb3629aeccb44b2a28d3344c7675d2f
 )
 ==========================
 assert(exp2(0.5L)== SQRT2); //Only 52 mantissa bits are equal
 ==========================
 real n = frexp(0x1p-16384L, x); //value is too small to fit in double
 ==========================

 real y = vals[i][1];
 real z = vals[i][2];
 real h = hypot(x, y);
 For some values only 52 mantissa bits are equal
 ==========================
 assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
 //Only 52 mantissa bits are equal
 ==========================
 assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
 Fails in exactly the same way on dpaste:
 http://dpaste.dzfl.pl/4c794ab8
 ==========================
 assert(pow(x, neg3) == 1 / (x * x * x));
 //Only 52 mantissa bits are equal
 ==========================
 assert(feqrel(real.min_normal / 8, real.min_normal / 17) == 3);
 //feqrel returns spectacular -732 equal bits. But it's the same on x86
 //with double so it's a bug in the test case. I can't fix it as I
 //don't know what it's supposed to do

These are problems that std/math does assume 80bit precision in most
of it's tests.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Aug 22 2013

Johannes Pfau <nospam example.com> writes:

Am Fri, 23 Aug 2013 01:34:39 +0200
schrieb Iain Buclaw <ibuclaw ubuntu.com>:
 
 Make Don aware of this. But looks ok to me.  Does it fail in the same
 way for double on x86/x86_64?

If I modify frexp to use double instead of real it also fails on
x86 in the same way:
http://dpaste.dzfl.pl/72725240


But the double code path is not used on x86. x86 always uses the real
version and therefore doesn't show this issue. I'll file a pull request
on github and ping Don about this.

Aug 23 2013

Johannes Pfau <nospam example.com> writes:

Am Fri, 16 Aug 2013 18:33:14 +0200
schrieb "Iain Buclaw" <ibuclaw 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?

Do you have any uncommitted changes for std.math? There's one remaining
test that fails on the auto-tester and on my machine:
http://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=50062&logid=13

In std.math, line 1947:
assert(expi(1.3e5L) == cos(1.3e5L) + sin(1.3e5L) * 1i);

seems like constant folding at work again, this passes:
--------
    real input = 1.3e5L;
    assert(expi(1.3e5L) == cos(input) + sin(input) * 1i);
--------

Aug 23 2013

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 23 August 2013 15:04, Johannes Pfau <nospam example.com> wrote:
 Am Fri, 16 Aug 2013 18:33:14 +0200
 schrieb "Iain Buclaw" <ibuclaw 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?

 Do you have any uncommitted changes for std.math? There's one remaining
 test that fails on the auto-tester and on my machine:
 http://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=50062&logid=13

 In std.math, line 1947:
 assert(expi(1.3e5L) == cos(1.3e5L) + sin(1.3e5L) * 1i);

 seems like constant folding at work again, this passes:
 --------
     real input = 1.3e5L;
     assert(expi(1.3e5L) == cos(input) + sin(input) * 1i);
 --------

Weird, I've never noticed this when running on 32bit/64bit test
machines locally (maybe because I use gcc-4.9 development?)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Aug 23 2013

D Programming

C/C++ Programming

Other

D.gnu - ARM testers, make note.