[patch] put DPD decimal float support in shared libgcc

Jakub Jelinek jakub@redhat.com
Wed Aug 13 13:20:00 GMT 2008


On Tue, Aug 12, 2008 at 03:16:20PM -0700, Janis Johnson 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.
> 
> Bootstrapped and regression-tested on powerpc64-linux with -m32/-m64.
> Bootstapped with only C and minimally tested on x86_64-linux for both
> BID and DPD decimal float support.  OK for trunk?

I think the important question is how much bigger this will make libgcc_s,
how many extra runtime relocations it will have and how much bigger will be
the writable segment of it.  Looking just at my x86_64-linux
libgcc.a, I see 100 non-decimal-float objects, together ~ 700KB, and then
114 decimal-float objects, together almost 5MB.  libgcc_s is a small library
which e.g. basically every C++ binary and many C binaries link against,
DFP is rarely used, so making libgcc_s library 8 times bigger for something
rarely used is IMNSHO a very bad idea.  IMHO it is much better if you put
it into libdfp.a/libdfp_s.so.1 and arrange for it being linked when needed
(see how libgcc_s already uses --as-needed ... --no-as-needed).
libgcc_s shouldn't be a kitchen sink library (nor libc should be).

	Jakub



More information about the Gcc-patches mailing list