decimal floating point

[Joseph Myers]

On Wed, 3 Dec 2025, Jakub Jelinek via Gcc wrote:

> > My next question is, does anyone know how the decision is made
> > about which dfp intrinsics to build into libgcc?  For x86_64,
> > at least, it seems to use some Intel-derived code underneath
> > libgcc/config/libbid.  But there's also a copy of libdecnumber,
> > which I believe is based on Cowlishaw's work at IBM.  (Perhaps
> > libdecnumber is used on platforms where DPD is required?)
> 
> The basic DFP support is in libgcc (again, for many years), but
> intentionally only in libgcc.a and not in libgcc_s.so.1, because it would
> quadruple the size of .text section of that library and add further
> more than 2MB in .rodata (current library has < 3KB .rodata), for something
> that 99.99% programs don't use.

There is definitely a speed/space trade-off in how much data you use for 
conversions between binary and decimal FP (the thing that takes a huge 
amount of data in libbid, I think) - you could store less precomputed data 
at the expense of needing to do more multiplications at runtime as part of 
the conversion.  (And for whatever approach is used you need to verify 
that the precision is in fact enough for all conversions to be correctly 
rounded - this is a well-understood problem, where the worst cases for 
correct rounding at each exponent can be found using continued fractions 
to find all the close rational approximations to numbers of the form 
2^a/10^b without needing any larger exhaustive search for worst cases.)

Note that libgcc's binary-to-DFP conversions aren't correctly rounded on 
targets using DPD - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97635 - 
and conversions aren't correctly rounded in libdfp either - 
https://github.com/libdfp/libdfp/issues/29 .

Having arithmetic functions in two different libraries is a problematic 
design as it means which version you get is very sensitive to link order.  
That doesn't say where a single implementation ought ideally to be, though 
the DFP rounding mode (sometimes hardware, sometimes TLS for software DFP 
implementation) needs to be included in fenv_t and femode_t by the 
<fenv.h> functions working with those types.  And if any implementations 
go in glibc, that doesn't say whether they go in libc.so / libm.so shared 
libraries, or in separate libc_dfp / libm_dfp that are linked with 
AS_NEEDED in linker scripts (although the general trend lately has been to 
reduce the number of shared libraries in glibc and merge more things into 
libc.so - libanl, libdl, libpthread, librt and libutil are now just 
placeholders).

-- 
Joseph S. Myers
josmyers@redhat.com