[OE-core] libm accuracy, eglibc compared to glibc

[Stanacar, StefanX]

Hello,

I just want to point out that this looks very similar to a qemuppc
machine bug we've seen before with libm and floor() call:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854

It was fixed with:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2a48e9007cc92fedfdb6919411859fb943eacc94

HTH,
Stefan

On Wed, 2014-03-12 at 15:30 +0000, Mats Kärrman wrote:
> Hi,
> 
> I face a problem with libm. With my Dora build the following assertion doesn't hold:
> 
> sqrt( pow( sqrt( 2.0 ), 4.0 ) ) == 2.0
> 
> 1) With my old OE-classic / glibc-2.9 / PowerPC-hf it holds.
> 2) With my Debian desktop PC / glibc-2.17 / amd64 it holds.
> 3) With my new OE-core Dora / eglibc-2.18 / PowerPC-hf it doesn't hold.
> 
> Close enough one can think but the standardized test case I run requires the result to be 2.0.
> A simple test program:
> --------------------------------------------------------------------
> #include <stdio.h>
> #include <math.h>
> 
> int main(){
> 
> 	double two = 2.0;
> 	double four = 4.0;
> 
> 	double s1 = sqrt(two);
> 	printf("sqrt(%.20f) = %.20f\n", two, s1);
> 	double p   = pow(s1, four);
> 	printf("pow(%.20f, %.20f) = %.20f\n", s1, four, p);
> 	double s2 = sqrt(p);
> 	printf("sqrt(%.20f) = %.20f\n", p, s2);
> 
> }
> --------------------------------------------------------------------
> 
> results from 1 and 2 (identical):
> sqrt(2.00000000000000000000) = 1.41421356237309514547
> pow(1.41421356237309514547, 4.00000000000000000000) = 4.00000000000000088818
> sqrt(4.00000000000000088818) = 2.00000000000000000000
> 
> results from 3:
> sqrt(2.00000000000000000000) = 1.41421356237309492343
> pow(1.41421356237309492343, 4.00000000000000000000) = 3.99999999999999866773
> sqrt(3.99999999999999866773) = 1.99999999999999955591
> 
> Does anyone know if this is a known "feature" of eglibc or know any other reason
> for this difference?
> 
> Best Regards,
> Mats