www.digitalmars.com         C & C++   DMDScript  

D.gnu - Unittest tester.

reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
We now have 6 currently failing unittests.

Current failing unittests:

core.exception.AssertError libphobos/src/std/internal/math/errorfunction.d(222):
unittest failure
core.exception.AssertError libphobos/src/std/internal/math/gammafunction.d(367):
unittest failure
core.exception.AssertError libphobos/src/std/typecons.d(3293):
unittest failure
core.exception.AssertError libphobos/src/std/range.d(2995):
unittest failure
core.exception.AssertError libphobos/src/std/math.d(336):
unittest failure
core.exception.AssertError libphobos/src/std/conv.d(2524):
unittest failure


Anyone interested in fixing these or raising bugs with minimal 
test cases?  Our goal is to get 100% pass across the board by the 
end of the month. :-)


Regards
Iain.
May 14 2013
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 14 May 2013 18:59:14 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 We now have 6 currently failing unittests.
 
 Current failing unittests:
 
 core.exception.AssertError libphobos/src/std/internal/math/errorfunction.d(222):
 unittest failure
 core.exception.AssertError libphobos/src/std/internal/math/gammafunction.d(367):
 unittest failure

At least the second problem is caused by a difference in the exp inline asm version used in dmd and the core.stdc.math.expl function used in gdc. At first I though the iasm version might be more precise, especially as we just alias expl(real) to exp(double). But a short test with mathematica suggests that the iasm version is less precise (or even wrong?) and the numbers where determined with the iasm version, so it seems this is 'not our bug'. I guess I'll have to ask Don about this right? http://dpaste.dzfl.pl/5b33b8ad
May 17 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf300512bec7445804dcf1fccd
Content-Type: text/plain; charset=ISO-8859-1

On 17 May 2013 21:09, Johannes Pfau <nospam example.com> wrote:

 Am Tue, 14 May 2013 18:59:14 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 We now have 6 currently failing unittests.

 Current failing unittests:

 core.exception.AssertError libphobos

 unittest failure
 core.exception.AssertError libphobos

 unittest failure

At least the second problem is caused by a difference in the exp inline asm version used in dmd and the core.stdc.math.expl function used in gdc. At first I though the iasm version might be more precise, especially as we just alias expl(real) to exp(double). But a short test with mathematica suggests that the iasm version is less precise (or even wrong?) and the numbers where determined with the iasm version, so it seems this is 'not our bug'. I guess I'll have to ask Don about this right? http://dpaste.dzfl.pl/5b33b8ad

http://dpaste.dzfl.pl/bb319763 -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf300512bec7445804dcf1fccd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 7 May 2013 21:09, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:nos= pam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> Am Tue, 14 May 2013 18:59:14 +0200<br> schrieb &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">i= buclaw ubuntu.com</a>&gt;:<br> <div class=3D"im"><br> &gt; We now have 6 currently failing unittests.<br> &gt;<br> &gt; Current failing unittests:<br> &gt;<br> &gt; core.exception.AssertError libphobos/src/std/internal/math/errorfuncti= on.d(222):<br> &gt; unittest failure<br> &gt; core.exception.AssertError libphobos/src/std/internal/math/gammafuncti= on.d(367):<br> &gt; unittest failure<br> <br> </div>At least the second problem is caused by a difference in the exp inli= ne<br> asm version used in dmd and the core.stdc.math.expl function used in<br> gdc. At first I though the iasm version might be more precise,<br> especially as we just alias expl(real) to exp(double).<br> <br> But a short test with mathematica suggests that the iasm version is<br> less precise (or even wrong?) and the numbers where determined with the<br> iasm version, so it seems this is &#39;not our bug&#39;. I guess I&#39;ll h= ave to<br> ask Don about this right?<br> <br> <a href=3D"http://dpaste.dzfl.pl/5b33b8ad" target=3D"_blank">http://dpaste.= dzfl.pl/5b33b8ad</a><br> <br> </blockquote></div><br></div><div class=3D"gmail_extra">You will also find = that be behaviour matches core.stdc.exp2l(LOG2E*x);<br><br><a href=3D"http:= //dpaste.dzfl.pl/bb319763">http://dpaste.dzfl.pl/bb319763</a><br clear=3D"a= ll"> </div><div class=3D"gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ?= p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --20cf300512bec7445804dcf1fccd--
May 17 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 14 May 2013 18:59:14 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 core.exception.AssertError libphobos/src/std/typecons.d(3293):

Caused by not implemented NRVO. Reduced: http://dpaste.dzfl.pl/6c55ec20
May 18 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--485b397dd491b8836204dd04ee31
Content-Type: text/plain; charset=ISO-8859-1

On 18 May 2013 22:15, Johannes Pfau <nospam example.com> wrote:

 Am Tue, 14 May 2013 18:59:14 +0200
 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 core.exception.AssertError libphobos/src/std/typecons.d(3293):

Caused by not implemented NRVO. Reduced: http://dpaste.dzfl.pl/6c55ec20

Thanks, care to throw this in a bug report so is not forgotten? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --485b397dd491b8836204dd04ee31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 8 May 2013 22:15, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto:nos= pam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Am Tue, 14 May 2013 18:59:14 +0200<br> schrieb &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">i= buclaw ubuntu.com</a>&gt;:<br> <br> </div>&gt; core.exception.AssertError libphobos/src/std/typecons.d(3293):<b= r> <br> Caused by not implemented NRVO. Reduced:<br> <a href=3D"http://dpaste.dzfl.pl/6c55ec20" target=3D"_blank">http://dpaste.= dzfl.pl/6c55ec20</a><br> </blockquote></div><br></div><div class=3D"gmail_extra"><br>Thanks, care to= throw this in a bug report so is not forgotten?<br clear=3D"all"></div><di= v class=3D"gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p)= =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --485b397dd491b8836204dd04ee31--
May 18 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 14 May 2013 18:59:14 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 core.exception.AssertError libphobos/src/std/range.d(2995):

This is a weird bug: This is what happens: Struct Take consists of an int and a size_t. In between those two we have 4 bytes padding on x86_64. If GCC returns this struct from a function it just ignores the padding and the padding remains 'unchanged' from the 'original' value. Test case: http://dpaste.dzfl.pl/cce31911 Cannot reproduce with dpaste gdc 2.060 so this might be a regression. Some ASM: Optimized & inlined: -------------- 0x000000000040265a <+26>: movl $0x1,(%rsp) 0x0000000000402661 <+33>: movq $0x5,0x8(%rsp) 0x000000000040266a <+42>: movl $0x1,0x10(%rsp) 0x0000000000402672 <+50>: movq $0x5,0x18(%rsp) 0x000000000040267b <+59>: callq 0x401bc0 <memcmp plt> -------------- Notice how gcc uses movl & movq. 0x4(%rsp) is not being accessed / initialized. Not optimized: -------------- 0x000000000040267b <+27>: callq 0x4025e0 <_D5range4takeFimZS5range4Take> 0x0000000000402680 <+32>: mov %eax,%ecx 0x0000000000402682 <+34>: mov %rdx,%rax 0x0000000000402685 <+37>: mov %ecx,-0x50(%rbp) 0x0000000000402688 <+40>: mov %rax,-0x48(%rbp) -------------- Here GCC uses the 4 byte registers for the int. We could force all local variables to be initialized to .init to fix this specific case, but I'm not sure if that would fix this bug completely. We also have to consider that the variables could be temporaries.... I wonder how C/C++ deals with this.
May 19 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 14 May 2013 18:59:14 +0200
schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:

 core.exception.AssertError libphobos/src/std/conv.d(2524):

http://dpaste.dzfl.pl/f995a4f3 Caused by a subtle difference when parsing floating point values in the compiler. ldc produces the same result as gdc. The asm generated for loading the 1.23456E+2 constant value is: dmd: -------- fldt 0x806f5dc #0x400ff120000000000000 fstpt -0x18(%ebp) movw $0x0,-0xe(%ebp) fldt 0x806f5e8 #0x4005f6e978d4fdf3b645 -------- gdc: -------- movabs $0xf6e978d4fdf3b646,%rcx mov $0x4005,%ebx #0x4005f6e978d4fdf3b646 -------- I think rounding at compile time could be the issue. The 1.23456E+2 value cannot be represented exactly with 80bit reals. If I calculate the mantissa manually I get the ...45 if I simply disregard the part of the mantissa which is > 63 bit. If I round after the 63. bit I get the ..46 result. So the question is: Is the rounding mode which should be used when parsing a floating point literal specified? I guess not. Then we could simply use a value in the test which fits completely into the mantissa, like 123.375 (I wonder whether .456 was used cause it fills all bits in the mantissa or whether that was by accident...)
May 20 2013