decimal floating point

[Joseph Myers]

On Thu, 12 Feb 2026, Steve Summit wrote:

> You may well know some/all of this, but: when compiling DFP-using
> expressions, for a platform without hardware DFP support
> (i.e. almost all of them), gcc emits calls to intrinsic functions
> implemented in libgcc.  At least for x86, the BID implementations
> of those intrinsics are based on the "Intel Decimal Floating-Point
> Math Library" at https://www.netlib.org/misc/intel/.  As far as
> I know this is a high-quality implementation; inspection and
> experimentation confirms that it is implementing settable
> rounding modes and setting f.p. exception flags.  The functions
> for interacting with those modes and flags are *not* named per
> C23, but it looks like most/all of the necessary functionality
> is there.
> 
> I'm not sure what form the "coordination with gcc" would take.

The functions involving fenv_t, femode_t etc. need to interact with the 
same state for rounding modes, exceptions etc. as the functions used for 
arithmetic.  Either libgcc needs to provide fully-featured functions (and 
glibc not provide those functions), or glibc needs to provide those 
functions (and libgcc not provide them).  The approach of having 
implementations in both libgcc and libdfp is not a good one.

For exceptions, that means that when there is hardware exceptions support, 
the software DFP functions need to raise the same exceptions, not just 
store them somewhere in a TLS variable.  (On x86, this might be either the 
x87 or the SSE exceptions, which are separate state in hardware but not 
distinguished as far as standard C is concerned.)

For rounding modes, if libgcc provides a TLS variable then glibc needs to 
know about it.

Also, TLS state for rounding modes needs to be shared across both the 
executable and the shared libraries in the process, so that DFP arithmetic 
in any of those objects refers to the same rounding mode.  This probably 
means it needs to be in a shared library (libc) - having separate hidden 
copies in each shared library in the process would not be consistent with 
having a single version of that state.

> But then what about the decimal versions of the math.h functions
> that *are* transcendental?  I'm going to say something that
> may sound badly heretical, but I don't believe that having
> high-quality decimal versions of the transcendental functions
> is any kind of a priority.  I think it will be Good Enough
> (at least as a first cut) to implement each function like sind64
> or logd64 as a simple-minded wrapper around the corresponding
> conventional function (i.e., plain sin or log), suffering the
> obvious double conversion between binary and decimal, and a
> likely loss of a ULP of accuracy or two.  (I've got a longer
> justification for this approach, but this email's getting long,
> so I'll save it for later.)

That's not at all good enough; it means massive loss of range in some 
cases and errors far outside the 9ulp maximum in the glibc testsuites.

> I will say that proper integration with fenv_t looks like it will
> be a challenge.  The existing fenv_t structure (at least as
> defined for x86) "corresponds to the layout of the block written
> by the 'fstenv' instruction", and doesn't look to be designed for
> expansion.  I suspect that some crafty employment of versioned
> symbols may be necessary here.

There are plenty of reserved bits in fenv_t and femode_t should should be 
usable for storing a DFP rounding mode (which only needs three bits).

> On the other hand, before looking at code, some people might
> prefer to read a semiformal proposal for the work, which I think
> I'll also start writing, if there's any interest.

So far I think the evidence is that there's not sufficient interest to 
integrate this in glibc.

-- 
Joseph S. Myers
josmyers@redhat.com