[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52163

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-02-08 15:34:32 UTC ---
On Wed, 8 Feb 2012, amodra at gmail dot com wrote:

> Correct.  In fact, I think it's a waste of space to put the soft-float
> functions in the normal ppc32 libgcc.  They really only belong in the nof
> libgcc.

My view is that while they may need to stay for ABI compatibility, it 
should be possible to build very small versions for that case from generic 
C code for all the functions where GCC will reliably generate the expected 
code (not a recursive call) from generic C - so they don't actually take 
up much space in libgcc.

SFtype __addsf3 (SFtype a, SFtype b) { return a + b; }

etc.

Doing this for Power is more complicated than for some architectures 
because of all the floating point variants including Xilinx and e500v1 
which do only single-precision in hardware - and some variants may do some 
operations in hardware but not others, for a given type (e.g. 
__builtin_isunordered may involve a libgcc function for e500).  But it's 
certainly feasible at the present state of the toplevel libgcc transition 
to control what functions are built from what sources on a per-multilib 
basis, testing the compiler used for that multilib to determine which 
floating-point configuration is applicable.  And similar issues of not 
needing certain functions in libgcc, other than for compatibility, apply 
to other targets as well (MIPS in particular) - the generic C versions 
referred to above will be of use for more targets than just Power.