This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] preliminary patch to move decimal float runtime to new libs
On Tue, 19 Aug 2008, H.J. Lu wrote:
> I guess it depends on which shared library the runtime DFP will be in.
> If DFP becomes the part of C/C++ standard and the DFP run-time support
> goes into libc.so, we will need libgcc_dfp.so for every application. I
> don't know if it is a good idea. I think we should first figure where the
> final runtime DFP wil be before we make a new DFP shared library.
Becoming part of the standard (which in any case doesn't appear to be
happening for C1x) does not mean going in libc.so; it might mean the
add-on is integrated into the standard glibc distribution, but still
builds a separate shared library, just like libm is separate although it
defines functions that are part of the standard, and just like various
parts of POSIX have their own libraries such as libpthread and librt.
Much the same applies to other TRs, draft TRs, etc., that might or might
not get integrated and define library facilities:
TR 18037 (embedded C - fixed point etc.; I don't know of an implementation
of the library facilities for GNU)
TR 19769 (extra character datatypes - this *is* expected to go into C1x,
but it only has four functions and there probably isn't much point in a
separate shared library for them; I don't know of an implementation of the
library facilities for GNU)
DTR 24731-1 (MS bounds-checking functions - rejected for glibc as long as
they aren't in the standard; I don't know of an implementation for GNU)
DTR 24731-2 (POSIX/GNU dynamic allocation functions - mostly already in
glibc, but not some of the wide character variants)
DTR 24732 (DFP - which we're discussing now)
DIS 24747 (special mathematical functions; I don't know of an
implementation for GNU)
--
Joseph S. Myers
joseph@codesourcery.com