Denys Vlasenko wrote:
On Wednesday 14 January 2009 16:28, Jie Zhang wrote:
Currently nextafterf in uClibc is just a wrapper of nextafter, which is
a double version. But this is not correct. Below is a test case:
#include <stdio.h>
#include <math.h>
int main ()
{
float a = 75563.570, b;
b = nextafterf (a, -0.0);
printf ("a = %f, b = %f\n", a, b);
return 0;
}
Run it on AMD64 with glibc:
a = 75563.570312, b = 75563.562500
Run it on Blackfin with uClibc:
a = 75563.570313, b = 75563.570313
A patch is attached. This patch copies nextafterf from glibc. Tested on
Blackfin with the above test case. If it's OK, please apply. Thanks.
Why the patch touches libm/s_nextafter.c (the double version)?
Your comment says nothing about it.
Sorry for not explain that.
math_opt_barrier and math_force_eval were added in glibc to fix glibc bug:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3306
When I copied nextafterf, I noticed this. So I modified nextafter, too.
You also did not remove the wrapper from float_wrappers.c
I indeed removed it in my patch.
I think math_opt_barrier macro should be either eliminated
or moved to its sole user, libm/s_nextafterf.c
nextafter also needs them. But if uClibc does not care of the spec on
this corner, they can be removed from both.
+weak_alias (__nextafterf, nextafterf)
Why do you need to have __nextafterf at all?
OK. It's the glibc equivalent of
libm_hidden_def(nextafterf)
I forgot to change it. Sorry.
Jie
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
