Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
May 14, 2013 Unittest tester. | ||||
---|---|---|---|---|
| ||||
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 17, 2013 Re: Unittest tester. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 Re: Unittest tester. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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 > /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 > > You will also find that be behaviour matches core.stdc.exp2l(LOG2E*x); http://dpaste.dzfl.pl/bb319763 -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; |
May 18, 2013 Re: Unittest tester. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 Re: Unittest tester. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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'; |
May 19, 2013 Re: Unittest tester. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 20, 2013 Re: Unittest tester. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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...) |
Copyright © 1999-2021 by the D Language Foundation