Joseph Myers wrote: > On Wed, 3 Dec 2025, Jakub Jelinek via Gcc wrote: >> ...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) ...
At first I thought you were talking about binary to/from decimal *string* conversion, but on closer reading, I guess you're talking about conversions between e.g. normal double and _Decimal64 -- which are not as easy to dismiss. (But still -- *megabytes* of data?! I hope that makes things *really* fast, to be worth that space.) > Having arithmetic functions in two different libraries is a problematic > design as it means which version you get is very sensitive to link order. I agree, and I hate having multiple versions, but it may be inevitable. My goal would be for *some* form of C23-compatible DFP to be available in gcc+glibc by default, but it would clearly want to be in a form that could get by without megabytes of precomputed data -- or unreasonably huge gobs of text space, either. So there might be a case to be made for having a second, non-default, higher-speed and/or better-accuracy version of a decimal math library that you could optionally, explicitly request. (But no, I don't know enough about linker scripts and the like to know if this would be reasonably feasible.) > 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. I haven't responded to you in the glibc thread yet, but at your suggestion I'm investigating this question now. > ...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). I've long wished that could be done for libm, too, but that's another story.
