This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [BZ #18875] Avoid excess precision in check against float zero
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 26 Aug 2015 14:24:32 +0000
- Subject: Re: [PATCH] [BZ #18875] Avoid excess precision in check against float zero
- Authentication-results: sourceware.org; auth=none
- References: <559C2EA4 dot 8030409 at redhat dot com> <20150826133745 dot GA17104 at gmail dot com>
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
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
(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