www.digitalmars.com         C & C++   DMDScript  

D.gnu - ARM testers, make note.

reply "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
next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling parent 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