This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RFC: avoiding "inexact" from x86 ceil / floor / trunc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 25 May 2016 14:40:20 +0000
- Subject: RFC: avoiding "inexact" from x86 ceil / floor / trunc
- Authentication-results: sourceware.org; auth=none
C99 and C11 allow but do not require ceil, floor, round and trunc to raise
the "inexact" exception for noninteger arguments. TS 18661-1 requires
that this exception not be raised by these functions. This aligns them
with general IEEE semantics, where "inexact" is only raised if the final
step of rounding the infinite-precision result to the result type is
inexact; for these functions, the infinite-precision integer result is
always representable in the result type, so "inexact" should never be
raised.
Whereas the fixes for generic versions of those functions simplified the
code by removing code that was present only to force "inexact" exceptions,
fixes for x86 ceil, floor, trunc (all formats for 32-bit; only long double
for x86_64) will complicate the code (and presumably make it slower): it's
not possible to save and restore the status word on its own, so it's
necessary to save and restore the whole floating-point environment with
fnstenv / fldenv to avoid raising spurious "inexact" (and in the long
double case, to merge "invalid" exceptions from sNaN operands into the
saved environment) - see the implementations of nearbyint functions for
similar code.
My question is: should we do anything special in this case to optimize
things for code that doesn't care about "inexact" being set? It's not
clear we have a good way to tell; GCC doesn't predefine a macro for
-fno-trapping-math. And __STDC_WANT_IEC_60559_BFP_EXT__ is about
declaring new identifiers, not changing semantics for existing ones.
My inclination is that handling the case of not caring about "inexact" is
better done in the compiler, in which case these functions can be inlined
rather than exporting separate versions from glibc. Unfortunately GCC
doesn't currently inline these functions in all the cases where it could
(or have an option to select TS 18661-1 semantics):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71278
--
Joseph S. Myers
joseph@codesourcery.com