When I added support for using soft-fp in libgcc
https://gcc.gnu.org/ml/gcc-patches/2006-03/msg00689.html, libgcc
configuration was still done in the gcc/ directory, meaning that the
variables set in makefile fragments could not depend on the multilib
being built. Thus, building the soft-fp code for powerpc64-linux-gnu
was disabled in the same way as had been done with fp-bit: the code
was built, but with #ifndef __powerpc64__ wrappers around it so that
the resulting objects were empty.
Now that libgcc configuration is done in the toplevel libgcc
directory, such uses of softfp_wrap_start / softfp_wrap_end are better
replaced by configure-time conditionals that determine whether to use
soft-fp for a given multilib. This patch does so for
powerpc*-*-linux*. The same would appear to apply to
powerpc*-*-freebsd* (using rs6000/t-freebsd64), but I have not made
any changes there. t-ppc64-fp is also used by AIX targets, but they
don't use soft-fp anyway so the changes are of no consequence to them.
The same principle of replacing softfp_wrap_start / softfp_wrap_end
with configure-time conditionals also applies to
softfp_exclude_libgcc2, which was intended for cases where soft-fp is
being used on hard-float multilibs and so it is desirable on those
multilibs for a few functions to come from libgcc2.c rather than
soft-fp (but the soft-fp versions would be more efficient on
soft-float multilibs). Now we have hardfp.c and t-hardfp, those are
better to use in that case, to minimize the size of the bulk of the
functions that are only present for ABI compatibility and should never
be called by newly compiled code.
I intend followup patches to switch 32-bit hard-float multilibs to use
t-hardfp as far as possible (for all non-libgcc2.c operations for
classic hard float; for all except __unord* for e500v2; for all SFmode
operations except __unordsf2 for e500v1). After that will come making
the soft-fp operations, in the remaining cases for which they are
built because they are actually needed for code compiled by current
GCC, into compat symbols when building for glibc 2.19 or later, so
that the glibc versions (with exception and rounding mode support) get
used instead (2.19 or later is needed for all the functions to be
exported from glibc as non-compat symbols). In turn, that is required
before implementing TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float
and e500, as that can only be properly effective when GCC-compiled
code is actually interoperating correctly with the exception and
rounding mode state used by fenv.h functions.
Tested with no regressions with cross to powerpc64-linux-gnu (in
addition, verified that stripped libgcc_s.so.1 is identical before and
after the patch). OK to commit?
2014-10-22 Joseph Myers jos...@codesourcery.com
* config.host (powerpc*-*-linux*): Only use soft-fp for 32-bit
configurations.
* config/rs6000/t-ppc64-fp (softfp_wrap_start, softfp_wrap_end):
Remove variables.
Index: libgcc/config/rs6000/t-ppc64-fp
===
--- libgcc/config/rs6000/t-ppc64-fp (revision 216519)
+++ libgcc/config/rs6000/t-ppc64-fp (working copy)
@@ -1,5 +1,2 @@
# Can be used unconditionally, wrapped in __powerpc64__ || __64BIT__ __ppc64__.
LIB2ADD += $(srcdir)/config/rs6000/ppc64-fp.c
-
-softfp_wrap_start := '\#ifndef __powerpc64__'
-softfp_wrap_end := '\#endif'
Index: libgcc/config.host
===
--- libgcc/config.host (revision 216519)
+++ libgcc/config.host (working copy)
@@ -990,7 +990,10 @@
extra_parts=$extra_parts crtbeginS.o crtendS.o crtbeginT.o ecrti.o
ecrtn.o ncrti.o ncrtn.o
;;
powerpc*-*-linux*)
- tmake_file=${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr
rs6000/t-crtstuff rs6000/t-linux t-softfp-sfdf t-softfp-excl t-dfprules
rs6000/t-ppc64-fp t-softfp t-slibgcc-libgcc
+ tmake_file=${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr
rs6000/t-crtstuff rs6000/t-linux t-dfprules rs6000/t-ppc64-fp t-slibgcc-libgcc
+ if test ${host_address} = 32; then
+ tmake_file=${tmake_file} t-softfp-sfdf t-softfp-excl t-softfp
+ fi
extra_parts=$extra_parts ecrti.o ecrtn.o ncrti.o ncrtn.o
md_unwind_header=rs6000/linux-unwind.h
;;
--
Joseph S. Myers
jos...@codesourcery.com
