Re: [patch] put DPD decimal float support in shared libgcc

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 12 Aug 2008, H.J. Lu wrote:

> On Tue, Aug 12, 2008 at 3:16 PM, Janis Johnson <janis187@us.ibm.com> wrote:
> > By design, the arithmetic/comparison/conversion functions for decimal
> > floating point support were originally added only to the static
> > libgcc because we thought the APIs might change later.  We'd now like
> > to include this support in the shared version of libgcc as well.
> >
> > I've done this only for the DPD support because I'm not clear on how
> > much of the BID support would need to be made visible outside of
> > libgcc.
> >
> 
> I'd like to see a complete DFP support, including I/O. I am not sure
> where DFP I/O belongs. At gcc summit, there is a suggestion for
> a supplement C runtime library, similar to libsupc++, to provide
> additional runtime support for gcc. If such a library, saying libsupc,
> supports DFP I/O, among other things, I prefer the BID intrinsics in
> libsupc over shared libgcc.

The printf support belongs in libc, in principle, and clearly it should 
apply to all printf-family functions in libc whether or not standard.  (I 
don't know whether it's possible to implement it in a separate library 
that registers a GNU printf handler at startup.)  There's a glibc add-on, 
present on a branch in the EGLIBC repository, and EGLIBC is happy to 
accept it on trunk (subject to assignments and review) including 
appropriately conditional changes to headers in core libc so it doesn't 
need to carry around copies of the headers.

DFP is only supported for certain GNU/Linux targets at present, so the 
issue of how to work with non-GNU, non-source-available C libraries does 
not arise.  In general I see no reason for these functions to be handled 
differently from all the other standard functions declared in the same 
standard headers.  We may provide replacements for standard functions 
missing or broken on a target (this could be libsupc) just as we fix 
headers with fixincludes, but for GNU systems we should aim to get the 
functions into GNU libc just as we shouldn't fix GNU headers with 
fixincludes without also getting the fix upstream - the expectation should 
be that with current GNU libc (appropriately configured, so with DFP 
support if GCC is being configured with DFP support) no replacement libc 
functions are provided by GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com