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]

RFC: avoiding "inexact" from x86 ceil / floor / trunc

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 

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):

Joseph S. Myers

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