Working around floating-point / integer conversion issues

[Steven Munroe]

On Tue, 2015-09-29 at 13:25 +0000, Joseph Myers wrote:
> 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 problem here is that the V1 PowerPC ISA allowed 32-bit processor
implementations to not implement the Floating Convert From Integer
Doubleword (fcfid/fcfidz) instructions. Instead the code inserted a
magic exponent then did a fsub (to remove the implied hidden bit) which
can result in -0.0. 

As of PowerISA-2.01 the these instructions where required, even for
32-bit processors. For 64-bit processors, these instructions (Floating
Convert To/From Integer Doubleword [Round toward zero]) where always
required.

> * 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?
> 
I have no objection. Also as correct implementations from /powerpc32/fpu
can still be used.