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

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

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.

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