Working around floating-point / integer conversion issues

[Joseph Myers <joseph at codesourcery dot com>]

There are several glibc libm bugs arising from issues with conversions 
between floating-point and integers (both libgcc and inline code generated 
by GCC):

* On powerpc32 hard-float, older processors, GCC generates conversions 
from integers to floating point that wrongly convert integer 0 to -0 
instead of +0 in FE_DOWNWARD mode.  This in turn results in logb and a few 
other functions wrongly returning -0 when they should return +0.  Bug 
16423 (which is really a duplicate of bug 887, dubiously closed on the 
basis of a GCC change that only applies to newer processors).

* The default libgcc conversions from floating point to double-word 
integers can raise spurious "inexact" exceptions when the argument is an 
integer, resulting in such exceptions from llrint (at least for powerpc32, 
again in the case of older processors).  Bug 16422.

* GCC conversions (libgcc or inline) from floating point to integers can 
fail to raise the "invalid" exception for out-of-range arguments, 
resulting in that exception being missing from lrint / llrint / lround / 
llround (which rely on casts to raise it).  Bugs 15470, 16399.

Since these issues all admit reasonably self-contained local workarounds, 
I propose that we should be willing to put such workarounds in glibc.  
Where the workarounds involve conditional code in architecture-independent 
files, there would be a sysdeps header or headers, with the 
sysdeps/generic version defining macros to 0 (workarounds disabled) and 
versions for architectures needing the fix defining such macros to 1, 
possibly conditional on architecture variants, compiler versions or the 
results of configure tests (whatever seems appropriate in each case) - so 
the architecture-independent code would then have conditionals of the form 
"if (FIX_INT_FP_CONVERT_ZERO)".  The architecture headers would have 
comments referencing the relevant GCC issues.

Any comments or objections?

-- 
Joseph S. Myers
joseph@codesourcery.com