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 [email protected]
