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.

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

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';

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

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';

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.

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...)