D.gnu - Unittest tester.
- Iain Buclaw (19/19) May 14 2013 We now have 6 currently failing unittests.
- Johannes Pfau (11/19) May 17 2013 At least the second problem is caused by a difference in the exp inline
- Iain Buclaw (6/27) May 17 2013 You will also find that be behaviour matches core.stdc.exp2l(LOG2E*x);
- Johannes Pfau (4/5) May 18 2013 Caused by not implemented NRVO. Reduced:
- Iain Buclaw (5/10) May 18 2013 Thanks, care to throw this in a bug report so is not forgotten?
- Johannes Pfau (36/37) May 19 2013 This is a weird bug:
- Johannes Pfau (29/30) May 20 2013 http://dpaste.dzfl.pl/f995a4f3
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
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 failureAt 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
Iain Buclaw <ibuclaw ubuntu.com> 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>: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';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 failureAt 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
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
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>:Thanks, care to throw this in a bug report so is not forgotten? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';core.exception.AssertError libphobos/src/std/typecons.d(3293):Caused by not implemented NRVO. Reduced: http://dpaste.dzfl.pl/6c55ec20
May 18 2013
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
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: -------- fstpt -0x18(%ebp) movw $0x0,-0xe(%ebp) -------- gdc: -------- movabs $0xf6e978d4fdf3b646,%rcx -------- 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