On Tue, 12 Jul 2011, Rainer Orth wrote:
> One odd thing out is that the lm32 snippet misses
>
> softfp_exclude_libgcc2 := y
>
> compared to the new t-softfp-sfdf. I'm currently handling this since I
> cannot tell if this is intentional or just an accident.
The general rule is that softfp_exclude_libgcc2 := y is to be avoided
where possible - and after this move it should be possible (in separate
patches) to eliminate the remaining instances of it.
Specifically, if all multilibs for a target are soft-float and using
soft-fp, then you shouldn't need softfp_exclude_libgcc2 := y, because it's
more efficient to implement the floating-point functions from libgcc2.c
directly using soft-fp instead of through the libgcc2.c wrappers around
other operations that will end up calling soft-fp functions. The use of
softfp_exclude_libgcc2 := y is if a target has both hard and soft float
multilibs, because the libgcc2.c versions are better for the hard float
multilibs and it wasn't easy to choose between them based on the multilib.
With soft-fp configuration in the toplevel libgcc directory, the libgcc
configure script can select different configuration files depending on the
multilib. For the soft-float multilibs it can select the soft-fp files
and disable the libgcc2.c versions of these functions. For hard-float
multilibs, the functions outside libgcc2.c aren't really needed as they
won't actually be called; for ABI compatibility they should stay in libgcc
if they were already there, but it would be best to keep the size of
libgcc down by compiling them from trivial code such as "float __addsf3
(float a, float b) { return a + b; }". (Some cases such as Power e500v1 -
hardware "float", software "double" - are more complicated, but the same
general principles still apply.)
In addition to the cases for whether TFmode is involved that you noted,
there are cases for whether TImode is involved as well. See
libgcc/config/i386/32/t-fprules-softfp. With the move to toplevel, that
file has a kludge to remove TImode functions that has no good reason to
exist; the 32-bit multilibs should simply not include "ti" in
softfp_int_modes, rather than including it then overriding some of the
variables generated from that setting.
Configure tests could also make a better replacement for softfp_wrap_start
and softfp_wrap_end.
Given the complexity of the symbol versioning setup for this code for
x86-linux (32-bit and 64-bit) it would be a good idea to verify that the
exported symbols in shared libgcc are the same, at the same versions,
before and after the patch, for each of 32-bit and 64-bit.
--
Joseph S. Myers
jos...@codesourcery.com
