Do not build soft-fp code at all for powerpc64-linux-gnu

Programming / Compilers / GCC - jsm28 [138bc75d-0d04-0410-961f-82ee72b054a4] - 22 October 2014 12:29 UTC

When I added support for using soft-fp in libgcc , 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 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).

- 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.

e707b8c Do not build soft-fp code at all for powerpc64-linux-gnu.
libgcc/ChangeLog | 7 +++++++
libgcc/config.host | 5 ++++-
libgcc/config/rs6000/t-ppc64-fp | 3 ---
3 files changed, 11 insertions(+), 4 deletions(-)

Upstream: gcc.gnu.org

  • Share