Re: Working around floating-point / integer conversion issues

[Rich Felker <dalias at libc dot org>]

On Tue, Sep 29, 2015 at 01:25:10PM +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).

I agree the closure was dubious, but this is clearly a gcc bug and
should be fixed for the older processors too.

> * 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.

This also sounds like a gcc bug.

> * 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.

Isn't conversion from floating point to integer UB when the value is
out of range? In this case it's a bug for glibc to rely on it
producing invalid; it's a bug to even perform the conversion in the
first place.

> 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?

Not a strong objection, but I think the first two would all be
misplaced fixes. Application and third-party library code is affected
by these bugs too and they really just need to be fixed at the source.
If you do move forward with working around them in glibc I just hope
this does not reduce the interest in fixing them on the gcc side...

Of course I have no objection to fixing the UB in glibc.

Rich