This is the mail archive of the
mailing list for the glibc project.
Working around floating-point / integer conversion issues
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Tue, 29 Sep 2015 13:25:10 +0000
- Subject: Working around floating-point / integer conversion issues
- Authentication-results: sourceware.org; auth=none
There are several glibc libm bugs arising from issues with conversions
between floating-point and integers (both libgcc and inline code generated
* 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