Bug#855606: sqrt() regression on powerpc/jessie

2017-02-23 Thread James Cloos 
> Christoph Berg  writes:

> Jessie: 0X1.C48C6001F0ABFP+3
> Sid:0X1.C48C6001F0ACP+3

Looking tat the code glibc switched from fsqrt to a software version,
resulting in the ulp difference.

I see on pgsql-hackers, though, that glibc has enabled fma and as a
result that difference is avoided.

So jessie's libc6 on ppc32 needs to include the fma patch or switch back
to using fsqrt.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#855606: sqrt() regression on powerpc/jessie

2017-02-23 Thread Christoph Berg 
Re: James Cloos 2017-02-21 
> The only ppc I have access to are those in the gcc farm and those (the
> online ones anyway) only run fedora and aix, so I cannot test it
> myself.
> 
> Except that everything else reports:
> 
>   0X 0X1.C48C6001F0ACP+3

Jessie: 0X1.C48C6001F0ABFP+3
Sid:0X1.C48C6001F0ACP+3

Christoph

Bug#855606: sqrt() regression on powerpc/jessie

2017-02-21 Thread James Cloos 
It may be a bit more informative to add:

   printf("0X %A\n", r);

to that main() to see exactly what is different between the two.

The only ppc I have access to are those in the gcc farm and those (the
online ones anyway) only run fedora and aix, so I cannot test it
myself.

Except that everything else reports:

  0X 0X1.C48C6001F0ACP+3

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#855606: sqrt() regression on powerpc/jessie

2017-02-20 Thread Christoph Berg 
Package: libc6
Version: 2.19-18+deb8u7
Severity: normal
Tags: jessie

The following C program produces different output on Jessie and Sid. I
believe the Sid output is the correct one, and in fact this is the
output that has been observed for the "point" (and "polygon")
regression tests for PostgreSQL on all platforms for the last 20 years
since the test got added.


$ cat sqrt.c
#include 
#include 
#include 

double
pg_hypot(double x, double y)
{
double  yx;

/* Some PG-specific code deleted here */

/* Else, drop any minus signs */
x = fabs(x);
y = fabs(y);

/* Swap x and y if needed to make x the larger one */
if (x < y)
{
double  temp = x;

x = y;
y = temp;
}

/*
 * If y is zero, the hypotenuse is x.  This test saves a few cycles in
 * such cases, but more importantly it also protects against
 * divide-by-zero errors, since now x >= y.
 */
if (y == 0.0)
return x;

/* Determine the hypotenuse */
yx = y / x;
return x * sqrt(1.0 + (yx * yx));
}


int main ()
{
//fesetround(FE_TONEAREST);
printf("fegetround is %d\n", fegetround());
double r = pg_hypot(10.0, 10.0);
printf("14 %.14g\n", r);
printf("15 %.15g\n", r);
printf("16 %.16g\n", r);
printf("17 %.17g\n", r);
return 0;
}


Jessie output:
fegetround is 0
14 14.142135623731
15 14.1421356237309
16 14.14213562373095
17 14.142135623730949

Sid output:
fegetround is 0
14 14.142135623731
15 14.142135623731
16 14.14213562373095
17 14.142135623730951


The Sid output is also observed when running the binary compiled on
Jessie on Sid, so it's a library issue, not a compiler/binary one.


The problem might be due to the fix for #843904.


FTBFS in postgresql-9.4 in jessie-pu:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4=powerpc=9.4.11-0%2Bdeb8u1=1487473754=0
FTBFS in postgresql-9.6 in jessie-backports:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6=powerpc=9.6.1-2~bpo8%2B1=1485184696=0

Thread on pgsql-hackers:
https://www.postgresql.org/message-id/20170220155819.m2s43pf2pvkes4pc%40msg.credativ.de

Christoph


signature.asc
Description: PGP signature