decimal floating point

Joseph Myers josmyers@redhat.com
Tue Nov 25 17:12:48 GMT 2025


On Tue, 25 Nov 2025, Steve Summit wrote:

> A week or two ago, I wrote:
> > ...my question for today is simply: How much appetite would there
> > be for full and fully-integrated dfp support within glibc?
> 
> Hmm.  Apparently there's not much interest in decimal floating
> point at all just now, or at least, not the way I brought it up.
> 
> But I am undeterred, and since no one said it was a bad idea :-),
> I'll post an RFC patch in a few days, containing a first tranche
> of prototype modifications, and see what people think of that.

I think it's necessary to coordinate with GCC before doing any changes, 
because the first step should be clearly defining where the functions for 
the underlying arithmetic, with proper support for exceptions and rounding 
modes, should go, so avoiding issues with whether you get exceptions and 
rounding modes support for software DFP depending on details of link order 
(see item 5 in my 2019 list).  And closely associated with that, before 
any DFP-specific APIs, would be ensuring that the TLS rounding mode for 
software DFP arithmetic (separate from the binary FP rounding mode) is 
properly included in fenv_t and femode_t and handled by the existing 
<fenv.h> functions.

Once there's a stable and reliable base of arithmetic and environment 
support, fe_dec_getround, fe_dec_setround and the FE_DEC_* macros could be 
added on top of that.  Then you'd need lots of infrastructure to support 
DFP in the existing testsuite code with the existing test inputs (plus any 
extra inputs of value specifically for DFP) before actual function 
implementations could be added.

I don't think DFP function implementations should be added without sorting 
out the underlying arithmetic first; I'd expect too many issues with tests 
failing for not working correctly with exceptions and rounding modes, or 
only working by accident in the testsuite context because of the link 
order it uses but not working for users in practice if libgcc ends up in a 
different position on the linker command line.

But at present the evidence is that there's insufficient interest to 
maintain such code if it were added.

-- 
Joseph S. Myers
josmyers@redhat.com



More information about the Libc-alpha mailing list