November 21, 2010
I just realized, that because of the bug in how array literals are treated, there are memory allocations involved. If there is a bug in array literal code, or in the memory allocation, it could well be triggered by a change in the environment.

It should be possible to track this down a bit more. Please, in gammafunction.d, around line 611, add the line:

    /* Resort to interval halving if not close enough. */
ihalve:

    dir = 0;
    di = 0.5L;
    for( i=0; i<400; i++ ) {
+   printf("%La %La %La\n", x0, x1, y0);
        if( i != 0 ) {
            x = x0  +  di * (x1 - x0);
            if( x == 1.0L ) {
                x = 1.0L - real.epsilon;

and also add an import core.stdc.stdio; in this file somewhere.

Also at line 704,

    if ( nflg ) {
        goto done;
    }
    nflg = 1;
    lgm = logGamma(a+b) - logGamma(a) - logGamma(b);

    for( i=0; i<15; i++ ) {
        /* Compute the function at this point. */
+   printf("NEWT %La %La %La\n", x, x0, x1);
        if ( i != 0 )
            y = betaIncomplete(a,b,x);
        if ( y < yl ) {


Then compile & run this:

import std.mathspecial;
import std.stdio;

void main()
{
writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18,
 0.0813601));
}
November 21, 2010
The results are below.  BTW, something funny is probably going on with the memory allocations and array literals and all because when I checked in the workaround for this (changeset 2185 http://dsource.org/projects/phobos/changeset/2185 ), it broke stuff and I had to revert it.

Results:

0x0.p+0 0x1p+0 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1p+0 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.1804eea8d2ecafb2p-4 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.1804eea8d2ecafb2p-5 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.04e0420638da04cp-5 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.e6153a2ee5fb55d2p-7 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.c4da30dcde0ea44p-9 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.890d1616fb7cb0ep-13 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.2818d1e2215bbbdcp-21 0x1.4d403f8b304a4aa8p-4
0x1.f88cc851df724acep-103 0x1.5012b5df54e94f6p-38 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.5012b5df54e94f6p-38 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.5012b5dfc125d422p-39 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.5012b5e0999edda4p-40 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.391906d83f397b3p-40 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.23b1705dc827e8fp-41 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.0fc0754e6ede4ce2p-43 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.d7bb43ed4b8a3cb8p-48 0x1.4d403f8b304a4aa8p-4
0x1.b0f21306a8a3f06ap-72 0x1.636033815363d902p-56 0x1.4d403f8b304a4aa8p-4
0x1.3d4f49d31c670614p-71 0x1.636033815363d902p-56 0x1.4d403f8b304a4aa8p-4
0x1.3d4f49d31c670614p-71 0x1.6362ae1fe70a11dp-57 0x1.4d403f8b304a4aa8p-4
0x1.3d4f49d31c670614p-71 0x1.6367a35d0e56836cp-58 0x1.4d403f8b304a4aa8p-4
0x1.3d4f49d31c670614p-71 0x1.4b1c4dad68a4e8cep-58 0x1.4d403f8b304a4aa8p-4
0x1.3d4f49d31c670614p-71 0x1.34841050c9b6aaccp-59 0x1.4d403f8b304a4aa8p-4
0x1.3d4f49d31c670614p-71 0x1.1fa9840b09d27c44p-61 0x1.4d403f8b304a4aa8p-4
0x1.fcba6abe87ee8baep-66 0x1.1fa9840b09d27c44p-61 0x1.4d403f8b304a4aa8p-4
0x1.fcba6abe87ee8baep-66 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4
0x1.4f5afe0ce690d95cp-63 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4
0x1.d73cd667715a5d4ep-63 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4
0x1.e086f094f0f3c592p-63 0x1.2f8f5760fe11f0ap-62 0x1.4d403f8b304a4aa8p-4
0x1.e086f094f0f3c592p-63 0x1.121349774e697e9ep-62 0x1.4d403f8b304a4aa8p-4
0x1.e086f094f0f3c592p-63 0x1.012b60e0e371b0b4p-62 0x1.4d403f8b304a4aa8p-4
0x1.e086f094f0f3c592p-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4
0x1.ef335416e5c498f4p-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4
0x1.f79d2b4fe7de9188p-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4
0x1.f8306a1e4276665ap-63 0x1.0003814474fc450ep-62 0x1.4d403f8b304a4aa8p-4
0x1.f8306a1e4276665ap-63 0x1.fc604d3e83e50ce6p-63 0x1.4d403f8b304a4aa8p-4
0x1.f8306a1e4276665ap-63 0x1.fa485bae632db9ap-63 0x1.4d403f8b304a4aa8p-4
0x1.f8306a1e4276665ap-63 0x1.fa23b805d24d9ec4p-63 0x1.4d403f8b304a4aa8p-4
0x1.f918ffdb6a9d2c52p-63 0x1.fa23b805d24d9ec4p-63 0x1.4d403f8b304a4aa8p-4
0x1.f918ffdb6a9d2c52p-63 0x1.f99e5bf09e75658cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f95bade6048948fp-63 0x1.f99e5bf09e75658cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f95bade6048948fp-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4
0x1.f96c5968ab045018p-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4
0x1.f974af29fe41d3acp-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4
0x1.f975410947366826p-63 0x1.f97d04eb517f573ep-63 0x1.4d403f8b304a4aa8p-4
0x1.f975410947366826p-63 0x1.f97966ed789af692p-63 0x1.4d403f8b304a4aa8p-4
0x1.f975410947366826p-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9772faf2f8c4692p-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f97741d547ba7af8p-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774312e7f9dfbap-63 0x1.f97753fb5fe8af5cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774312e7f9dfbap-63 0x1.f9774c1b18a5da4ep-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774797004fdd04p-63 0x1.f9774c1b18a5da4ep-63 0x1.4d403f8b304a4aa8p-4
NEWT 0x1.f97749d90c7adba8p-63 0x1.f9774797004fdd04p-63 0x1.f9774c1b18a5da4
NEWT 0x1.f9774afa12905afcp-63 0x1.f97749d90c7adba8p-63 0x1.f9774c1b18a5da4
NEWT 0x1.f9774a698f859b52p-63 0x1.f97749d90c7adba8p-63 0x1.f9774afa12905af
NEWT 0x1.f9774ab1d10afb28p-63 0x1.f9774a698f859b52p-63 0x1.f9774afa12905af
NEWT 0x1.f9774a8db0484b3cp-63 0x1.f9774a698f859b52p-63 0x1.f9774ab1d10afb2
NEWT 0x1.f9774a9fc0a9a332p-63 0x1.f9774a8db0484b3cp-63 0x1.f9774ab1d10afb2
NEWT 0x1.f9774a96b878f738p-63 0x1.f9774a8db0484b3cp-63 0x1.f9774a9fc0a9a33
NEWT 0x1.f9774a9b3c914d34p-63 0x1.f9774a96b878f738p-63 0x1.f9774a9fc0a9a33
NEWT 0x1.f9774a98fa852236p-63 0x1.f9774a96b878f738p-63 0x1.f9774a9b3c914d3
NEWT 0x1.f9774a97d97f0cb8p-63 0x1.f9774a96b878f738p-63 0x1.f9774a98fa85223
NEWT 0x1.f9774a9748fc01f8p-63 0x1.f9774a96b878f738p-63 0x1.f9774a97d97f0cb
NEWT 0x1.f9774a97913d8758p-63 0x1.f9774a9748fc01f8p-63 0x1.f9774a97d97f0cb
NEWT 0x1.f9774a97b55e4a08p-63 0x1.f9774a97913d8758p-63 0x1.f9774a97d97f0cb
NEWT 0x1.f9774a97a34de8bp-63 0x1.f9774a97913d8758p-63 0x1.f9774a97b55e4a08
NEWT 0x1.f9774a97ac56195cp-63 0x1.f9774a97a34de8bp-63 0x1.f9774a97b55e4a08
0x1.f9774a97a34de8bp-63 0x1.f9774a97ac56195cp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a34de8bp-63 0x1.f9774a97a7d20106p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a34de8bp-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a739562p-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a75e270cp-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a760ab6p-63 0x1.f9774a97a782f7f8p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a760ab6p-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a769d498p-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a76e6934p-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a76eb95ep-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a77100eep-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772874ap-63 0x1.f9774a97a772fddp-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772874ap-63 0x1.f9774a97a772f762p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772874ap-63 0x1.f9774a97a772bf56p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772874ap-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a7729f9ep-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772ad9p-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772ae84p-63 0x1.f9774a97a772bb82p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772ae84p-63 0x1.f9774a97a772b574p-63 0x1.4d403f8b304a4aa8p-4
0x1.f9774a97a772b1fcp-63

On 11/21/2010 12:38 PM, Don Clugston wrote:
> writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18,
>   0.0813601));
> }
> __

November 21, 2010
On 21.11.2010 20:18, David Simcha wrote:
> Can others on this mailing list please submit info about their CPUs (manufacturer and core type) and whether the unit tests pass?  My working hypothesis (mostly because I can't think of anything else that's at all plausible) is that this discrepancy is somehow hardware-related.  I'll start and give an example of what I'm looking for:
>
> Intel Penryn:  Pass
> AMD Brisbane:  Fail
I myself, very concerned with FP code producing slightly different
results on AMD and Intel,
so here are my results (exactly the same exe used through out):
AMD Phenom II: Fail  (Win7 64bit)
AMD Neo: Fail            (Win7 32bit)
Core 2 Duo: Pass       (WinVista 32bit)

I have a bad feeling about it...
>
> On 11/21/2010 1:19 AM, Don Clugston wrote:
>> On 21 November 2010 05:48, David Simcha<dsimcha at gmail.com>  wrote:
>>> More research into this issue:  I compiled the unittest.exe
>>> executable on my
>>> main (desktop) computer, ran it under my primary OS (Win7 64) and it
>>> failed..  I then ran the exact same executable (no recompile) on my
>>> Linux
>>> Partition (Ubuntu 10.10 64) using Wine and it failed.
>>>
>>> I then ran the exact same executable on my laptop on my primary OS
>>> (also
>>> Win7 64) and it passed.  I ran it on my laptop's Linux partition
>>> under Wine
>>> (Ubuntu 10.10 32) and it passed.
>>>
>>> The only difference between the two systems that might account for
>>> this is
>>> that the laptop has an Intel Penryn CPU, whereas the desktop as an AMD
>>> Brisbane CPU.  Does anyone know whether different x86 CPUs can produce
>>> subtly different floating point results when executing the exact
>>> same code?
>>> Alternatively, is it possible that some processor-specific
>>> optimizations to
>>> some function getting called by Don's code could be causing slightly
>>> different results?
>> That's _very_ interesting. The code in question doesn't use the C
>> runtime at all.
>> If it's the same exe, then the difference can only lie in the CPU or
>> in the environment.
>> Eg, if it starts with 80-bit floats disabled.
>> But the fact that every other test passes on your system, makes that
>> seem unlikely.
>> Does the failing system have execution protection enabled?
>>
>> The only documented floating point difference between AMD and Intel
>> that I know of, is that AMD
>> raises the invalid exception when loading an 80-bit NaN, but Intel
>> doesn't. BTW I found that difference
>> myself, and added it to Wikipedia. That difference is not relevant here.
>>
>> If the CPU itself is responsible for the difference, that's a CPU bug.
>> BTW this test was present in Tango for years, and nobody ever reported
>> this issue before.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

November 21, 2010
On 11/21/2010 9:18 AM, David Simcha wrote:
> Can others on this mailing list please submit info about their CPUs (manufacturer and core type) and whether the unit tests pass?  My working hypothesis (mostly because I can't think of anything else that's at all plausible) is that this discrepancy is somehow hardware-related.  I'll start and give an example of what I'm looking for:
> 
> Intel Penryn:  Pass
> AMD Brisbane:  Fail
> 

auto tester is an atom n280 (yeah, slow, but it's an otherwise unused box): pass

November 21, 2010
On Nov 21, 2010, at 1:35 PM, Brad Roberts wrote:
> 
> auto tester is an atom n280 (yeah, slow, but it's an otherwise unused box): pass

Intel Core 2 Duo: pass

I have an AMD X2 I can test as well, but it will take some time.

November 22, 2010
Intel Core 2 Duo:  Pass

-Lars



On Sun, 2010-11-21 at 12:18 -0500, David Simcha wrote:
> Can others on this mailing list please submit info about their CPUs (manufacturer and core type) and whether the unit tests pass?  My working hypothesis (mostly because I can't think of anything else that's at all plausible) is that this discrepancy is somehow hardware-related. I'll start and give an example of what I'm looking for:
> 
> Intel Penryn:  Pass
> AMD Brisbane:  Fail
> 
> On 11/21/2010 1:19 AM, Don Clugston wrote:
> > On 21 November 2010 05:48, David Simcha<dsimcha at gmail.com>  wrote:
> >> More research into this issue:  I compiled the unittest.exe executable on my
> >> main (desktop) computer, ran it under my primary OS (Win7 64) and it
> >> failed..  I then ran the exact same executable (no recompile) on my Linux
> >> Partition (Ubuntu 10.10 64) using Wine and it failed.
> >>
> >> I then ran the exact same executable on my laptop on my primary OS (also
> >> Win7 64) and it passed.  I ran it on my laptop's Linux partition under Wine
> >> (Ubuntu 10.10 32) and it passed.
> >>
> >> The only difference between the two systems that might account for this is that the laptop has an Intel Penryn CPU, whereas the desktop as an AMD Brisbane CPU.  Does anyone know whether different x86 CPUs can produce subtly different floating point results when executing the exact same code? Alternatively, is it possible that some processor-specific optimizations to some function getting called by Don's code could be causing slightly different results?
> > That's _very_ interesting. The code in question doesn't use the C
> > runtime at all.
> > If it's the same exe, then the difference can only lie in the CPU or
> > in the environment.
> > Eg, if it starts with 80-bit floats disabled.
> > But the fact that every other test passes on your system, makes that
> > seem unlikely.
> > Does the failing system have execution protection enabled?
> >
> > The only documented floating point difference between AMD and Intel
> > that I know of, is that AMD
> > raises the invalid exception when loading an 80-bit NaN, but Intel
> > doesn't. BTW I found that difference
> > myself, and added it to Wikipedia. That difference is not relevant here.
> >
> > If the CPU itself is responsible for the difference, that's a CPU bug.
> > BTW this test was present in Tango for years, and nobody ever reported
> > this issue before.
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> >
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos


November 25, 2010
With regard to the AMD vs Intel bug:

The previous results narrowed it down significantly, but I'm going to
need more info to fix this.
Please, somebody with AMD add this to line to
std.math.internal.gammafunction line  624, add an import
core.stdc.stdio; in the file,

            if( x == 0.0L ) {
                di = 0.5;
                x = x0  +  di * (x1 - x0);
                if( x == 0.0 )
                    goto under;
            }
            y = betaIncomplete( a, b, x );
+            printf("%d %La %La %La %La %La %La %La\n", i, x, y, di,
yl, yh, a, b);
            yp = (x1 - x0)/(x1 + x0);
            if( fabs(yp) < dithresh )
                goto newt;
            yp = (y-y0)/y0;
            if( fabs(yp) < dithresh )
                goto newt;

compile Phobos, and then run this program:

import std.mathspecial;
import std.stdio;

void main()
{
writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18,
 0.0813601));
}
November 25, 2010
I'll do it in a few days if noone else does, but right now I'm out of town for Thanksgiving and don't have access to my AMD computer.

On Thu, Nov 25, 2010 at 10:06 AM, Don Clugston <dclugston at googlemail.com>wrote:

> With regard to the AMD vs Intel bug:
>
> The previous results narrowed it down significantly, but I'm going to
> need more info to fix this.
> Please, somebody with AMD add this to line to
> std.math.internal.gammafunction line  624, add an import
> core.stdc.stdio; in the file,
>
>            if( x == 0.0L ) {
>                di = 0.5;
>                 x = x0  +  di * (x1 - x0);
>                 if( x == 0.0 )
>                    goto under;
>             }
>            y = betaIncomplete( a, b, x );
> +            printf("%d %La %La %La %La %La %La %La\n", i, x, y, di,
> yl, yh, a, b);
>            yp = (x1 - x0)/(x1 + x0);
>            if( fabs(yp) < dithresh )
>                goto newt;
>            yp = (y-y0)/y0;
>            if( fabs(yp) < dithresh )
>                goto newt;
>
> compile Phobos, and then run this program:
>
> import std.mathspecial;
> import std.stdio;
>
> void main()
> {
> writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18,
>  0.0813601));
> }
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/7d1c02bf/attachment-0001.html>
November 25, 2010
On 25.11.2010 18:06, Don Clugston wrote:
Ok, see results attached per CPU type.
> With regard to the AMD vs Intel bug:
>
> The previous results narrowed it down significantly, but I'm going to
> need more info to fix this.
> Please, somebody with AMD add this to line to
> std.math.internal.gammafunction line  624, add an import
> core.stdc.stdio; in the file,
>
>              if( x == 0.0L ) {
>                  di = 0.5;
>                  x = x0  +  di * (x1 - x0);
>                  if( x == 0.0 )
>                      goto under;
>              }
>              y = betaIncomplete( a, b, x );
> +            printf("%d %La %La %La %La %La %La %La\n", i, x, y, di,
> yl, yh, a, b);
>              yp = (x1 - x0)/(x1 + x0);
>              if( fabs(yp)<  dithresh )
>                  goto newt;
>              yp = (y-y0)/y0;
>              if( fabs(yp)<  dithresh )
>                  goto newt;
>
> compile Phobos, and then run this program:
>
> import std.mathspecial;
> import std.stdio;
>
> void main()
> {
> writefln("%a", betaIncompleteInverse(0x1.ff1275ae5b939bcap-41, 4.6713e18,
>   0.0813601));
> }
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: AMD_phenom_II.txt
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/db311284/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: amd_neo.txt
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/db311284/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: intel_core2.txt
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101125/db311284/attachment-0005.txt>
November 26, 2010
Thanks! That's fantastic. It clearly shows we have a one-bit
difference at iteration 25.
This now looks very much like a CPU bug.
I think that if I'm correct, this should be a reduced test case.

import std.mathspecial;
import std.stdio;

void main()
{
    real a = 0x1.ff1275ae5b939bcap-41L;
    real b = 0x1.034f2a66cd21p+62L;
    real x = 0x1.4f5afe0ce690d95cp-63L;
    real s = 0x1.0076fc5cc795a06cp+40L;

    real u = a * log(x);
    real t = logGamma(b) - logGamma(a) - logGamma(b) + u + log(s);
    real y = exp(t);
    writefln("%a %a %a %a", logGamma(a), logGamma(b), u, t);
    writefln("%a %a %a %a", log(s), log(x), log(a), log(b));
    assert(y==0x1.c91a61a8fc916338p-7L); // Intel
//    assert(y==0x1.c91a61a8fc91633ap-7L); // AMD
}

On my Intel box, this prints:

0x1.bba4a9f774f49d0ap+4 0x1.543ef272830d3ed4p+67 -0x1.5a8e8efc9cec0dbp-35 -0x1.1
16d582237016688p+2
0x1.bba4a9f774f4c37ap+4 -0x1.5b2fa254744c96d8p+5 -0x1.bba4a9f774fdd508p+4 0x1.57
e75c552cc1d47ep+5

I suspect that we'll ever see a difference in the last line, which
would indicate a one-bit error in log.
But if all the numbers are the same, and the assert still fails, it's
a one-bit error in exp.
If the values in the last line are the same, but the ones in the first
line are different, it's an error in poly.
Either way, if the assert fails on AMD, we're just about down the asm.