Re: Working around floating-point / integer conversion issues

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 29 Sep 2015, Rich Felker wrote:

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

GCC bug 67771.  Debian has been working around this in glibc since 2012.

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

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

No, unspecified result with "invalid" raised, under Annex F.  See the 
response to DR#442, "WG14 treats normative annexes such as Annex F as if 
they were linear extensions of the standard itself. When Annex F is 
requested via definition of __STDC_IEC_559__ then 6.5#5 is superseded and 
floating point exceptions become well defined.".  And, GCC bug 27682 in 
the powerpc case (having lots of separate target-specific bugs for such a 
generic issue doesn't seem helpful in this case, but probably most or all 
targets that support floating-point exceptions also have such issues).

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

GCC supports being built with a range of different compiler versions and 
should as far as possible work correctly and pass its tests with those 
compilers.  Having a GCC fix would not affect the use of workarounds for 
older versions until those older versions are no longer supported for 
building glibc.  And in these cases, making the library work correctly is 
straightforward so that seems more appropriate than doing something in the 
testsuite (whereas e.g. some signaling NaN issues can't be effectively 
worked around in the library and so do have optional disabling in the 
testsuite).

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

On the GCC side they are arguably missing features as much as bugs (Annex 
F / exceptions and rounding modes support has never been near complete and 
the interest in fixing this hasn't been there).

-- 
Joseph S. Myers
joseph@codesourcery.com