decimal floating point

[Steve Summit]

Joseph Myers wrote:
> On Tue, 25 Nov 2025, Steve Summit wrote:
> > > ...my question for today is simply: How much appetite would there
> > > be for full and fully-integrated dfp support within glibc?
>
> I think it's necessary to coordinate with GCC before doing any changes...
>...
> Once there's a stable and reliable base of arithmetic and environment 
> support...
>...
> I don't think DFP function implementations should be added without
> sorting out the underlying arithmetic first...

It's been a while since I started this thread, I know, but there
was a lot to unpack in Joseph's previous message, and it sparked
some investigations, which sparked some further investigations,
which took some time.  But I'm back.

The point about having "a stable and reliable base of arithmetic
and environment support" is well taken.  My own impression (which
may not be worth much) is that gcc's current support should be
more than adequate, although I also think that this issue might
not be a gating one, after all.

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.
It's clear enough (though this is so obvious I may be missing
something) that libgcc should be responsible for implementing
the intrinsics that gcc emits, and glibc should be responsible
for implementing the actual functions the user calls, as declared
in stdlib.h, math.h, etc.  So, yes, any decimal f.p. math that a
library function performs will depend on the quality (accuracy,
rounding mode, etc.) of the libgcc intrinsics.

For the purposes of this discussion, the operations performed by
those libgcc intrinsics are the four basic arithmetic functions,
the comparison operators, and conversions between decimal
f.p. types and other types.  (There are also implementations
of sqrt and fma; I'm not sure when/how they're used.)

However!  It turns out that, with the notable and nontrivial
exception of transcendental math.h functions like sin() and
log(), few if any of the C23 DFP library functions end up having
to do any nontrivial decimal arithmetic at all.  So for all
but the transcendental functions, having highest-quality
DFP arithmetic intrinsics to build on is not, I believe,
a prerequisite.

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.)

So my position is that highest-quality basic arithmetic
(including exceptions and configurable rounding and proper
integration with fenv_t), while certainly important in the
long run, is not a prerequisite for beginning work on some
of the, well, lower-hanging and more interesting fruit.
(Also, as I said, I don't get the impression that the current
gcc DFP intrinsics are too far from "highest-quality", already).
I think that any significant departures from "highest-quality"
can be filed as bugs, and documented, and fixed in due course,
without necessarily invalidating the rest of the effort.

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.

But aside from all that philosophizing, I think that (to the
extent that anyone is interested in DFP at all, a question which
I'm going to ask separately), it might be interesting to look at
some actual code.  I promised to post some RFC patches, but got
distracted, but I'm ready to do that.  It might also be useful
to push my modified code to a branch, for inspection, although
I don't know what this project's policy is for creating personal
branches.

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.

					Steve Summit
					scs@eskimo.com