[PATCH] Fix nextafterf

Jie Zhang jie.zhang at analog.com
Fri Feb 6 04:49:52 UTC 2009


Denys Vlasenko wrote:
> On Friday 06 February 2009 00:16, 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.
>>
>> You also did not remove the wrapper from float_wrappers.c
>>
>> I think math_opt_barrier macro should be either eliminated
>> or moved to its sole user, libm/s_nextafterf.c
>>
>>
>> +weak_alias (__nextafterf, nextafterf)
>>
>> Why do you need to have __nextafterf at all?
> 
> I fixed it, and applied it, but next time please send better patch.

Thanks for applying. But we might need

libm_hidden_def(nextafterf)

and reconsider if math_opt_barrier and math_force_eval are needed.


Jie


More information about the uClibc mailing list