This is the mail archive of the
mailing list for the glibc project.
Re: Working around floating-point / integer conversion issues
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 30 Sep 2015 13:54:50 -0500
- Subject: Re: Working around floating-point / integer conversion issues
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1509291248100 dot 9679 at digraph dot polyomino dot org dot uk>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
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
> * 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.