This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [BZ #18875] Avoid excess precision in check against float zero

On Wed, 26 Aug 2015, H.J. Lu wrote:

> 	[BZ #18875]
> 	* sysdeps/i386/fpu/w_exp10f.c: New file.
> 	* sysdeps/i386/fpu/w_exp2f.c: Likwise.
> 	* sysdeps/i386/fpu/w_expf.c: Likwise.

I don't really like having extra copies of the wrappers, which will mean 
more places to clean up when we eventually obsolete _LIB_VERSION and 
__kernel_standard and make the wrappers set errno directly.

The problem is: the functions return results with excess range and 
precision.  This seems a dubious thing to do anyway in C standard terms 
(not allowed for return statements under Annex F, but there's no actual 
statement that library functions return as if by a C return statement).  
Your fix works around this for the wrappers, so as to set errno and avoid 
test failures.  But if the underflow in the wrappers isn't all the way to 
zero, the wrappers might well return the original value with excess range 
and precision, and confuse any callers in much the same way the wrappers 
were confused.

I think it's better to do what I suggested in the bug and copy the code 
from atan2f to eliminate excess range and precision, and force underflow 
exceptions, for underflowing results, before the functions return to the 
wrappers at all.  You're still storing to the stack in order to get at a 
value without excess range and precision, just before returning to the 
wrapper rather than in the wrapper.  The same thing should be done for the 
double versions of these functions, which could have the issue just as 
much as the float versions depending on what code the compiler chooses to 
generate.  That way you avoid adding any architecture-specific versions of 
files where we don't already have them, just patch existing 
architecture-specific files.

(In either case, the general question of avoiding excess range and 
precision in return values from all libm functions is deferred; the patch 
would just deal with float and double versions of these three functions, 
for underflowing results.  The general issue is already mentioned at 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]