> A fix has been committed, but there's still a problem on loongson with
> libm updated:
> 
> $ ls -l /usr/lib/libm.so.*
> -r--r--r--  1 root  bin  926033 Feb 12 12:17 /usr/lib/libm.so.9.0
> $ cc -o expl expl.c -O2 -pipe -lm
> $ for in in 1 2 3 4 5 6 ; do ./expl ; done
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> theta == 1, pr == 0.606531, pr2 == 0.606531
> 

This is definitely a problem in gdtoa. The values are always computed
the same, but do not get printed correctly, as shown by this modified
test program. Both lines should print 0.606531 for the long doubles, but
don't always; this smells like an uninitialized value somewhere.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int
main(void)
{
        double theta = 1;
        long double lambda, pr, pr2;
        static const uint64_t zpr[2] = {
#ifdef __MIPSEL__
        0xa000000000000000ULL, 0x3ffe368b2fc6f960ULL
#else
        0x3ffe368b2fc6f960ULL, 0xa000000000000000ULL
#endif
        }, zpr2[2] = {
#ifdef __MIPSEL__
        0x9fe7aceb46aa619cULL, 0x3ffe368b2fc6f960ULL
#else
        0x3ffe368b2fc6f960ULL, 0x9fe7aceb46aa619cULL
#endif
        };

        lambda = (0.5*theta);
        pr = exp(-lambda);
        pr2 = expl(-lambda);

        printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
        printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, zpr[0], zpr[1],
            zpr2[0], zpr2[1]);
        exit(0);
}

Reply via email to