This patch does not take account of the issues with the powerpc-specific functions that I pointed out in <https://sourceware.org/ml/libc-alpha/2015-10/msg00921.html> when they were posted to libc-alpha. (Testcases covering those issues would be a good idea to put in the testsuite.)
The patch is also missing the sfp-machine.h changes to integrate with hardware exceptions and rounding modes (see what x86 does to get that support for __float128, for example - while you need to read floating-point state to get the rounding mode, you don't need to write it explicitly to raise exceptions as you can do that with appropriate computations on double that raise the same exceptions) - as previously noted to be missing in <https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00105.html> and <https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01768.html>. Roughly, you need to define _FP_DECL_EX FP_INIT_ROUNDMODE FP_RND_* (if the defaults aren't right for powerpc) FP_EX_* FP_HANDLE_EXCEPTIONS FP_TRAPPING_EXCEPTIONS FP_ROUNDMODE. I don't think you need the %exclude in libgcc-glibc.ver, because the existing .ver files won't have any mention of KFmode functions; %exclude should only be relevant if a mode with an old standard name is newly supported. You're listing conversions between KFmode and TImode in libgcc-glibc.ver. Those should indeed be in libgcc (when building 64-bit code, since TImode isn't supported for 32-bit code). But I don't see anything in t-float128 that would actually cause such functions to be built - do they actually end up in your library? (I'd expect you to need conditional code to add them.) Are you doing all comparisons with __cmpukf2 and __cmpokf2, or with a load of other functions as well? Right now you're building in eqkf2 gekf2 lekf2 unordkf2, and list yet more such functions e.g. __orderedkf2 __ungtkf2 in libgcc-glibc.ver. I'd expect libgcc-glibc.ver to need conversions from all of SImode, DImode and TImode (signed and unsigned) to KFmode, not just the TImode conversions currently listed there. I think you should enable existing __float128 testcases for powerpc targets supporting float128, where they don't have anything x86-specific. This might help show up any missing or broken libgcc functions. Especially the fp-int-convert-float128-* tests. I suppose you need to change e.g. /* { dg-do run { target i?86-*-* x86_64-*-* ia64-*-* } } */ to /* { dg-do run { target { float128 } } } */ /* { dg-add-options float128 } */ where float128 is a new effective-target, and a new dg-add-options case to add -mvsx in the powerpc case. (Well, you need more than that, so that in the powerpc case without VSX runtime support you compile but not execute, but you get the idea.) (Some of the existing tests may be under gcc.dg, some under gcc.target. A few may actually be architecture-specific, e.g. float128-truncdf-underflow.c is not applicable to powerpc because powerpc uses before-rounding tininess detection, and anything involving __float80 / x86 long double likewise, but most should be applicable to powerpc. Some, e.g. float128-exact-underflow.c, may apply to powerpc but require a glibc target for trapping exceptions, so they need to have an appropriate target constraint in addition to the above.) Testcase enablement can reasonably be a separate patch from libgcc support, but I think it's an important part of actually having much confidence that the feature is working properly. Will there be a separate patch to cause __mulkc3 and __divkc3 (complex arithmetic, using existing libgcc2.c code for a new mode) to be built? There's also the matter of __powikf2 (I'm not sure if calls to that can be generated right now without new built-in functions, or not). Are conversions between KFmode and decimal floating point being deferred for now (which seems reasonable, as I said in <https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html> - those in dfp-bit.c rely on strtod / sprintf, which of course won't work as an approach for KFmode)? x86 has a minimal set of built-in functions for __float128, __builtin_infq __builtin_huge_valq __builtin_fabsq __builtin_copysignq. Unless I've missed it, you don't seem to have these for powerpc. (They are needed for the libgcc2.c complex arithmetic functions.) Another thing that would help find missing libgcc functions is enabling libquadmath for powerpc (building with -mvsx) - though there isn't a libquadmath testsuite - missing functions would mean it fails to link (though this wouldn't find more obscure missing functions such as TImode conversions). Enabling libquadmath has another advantage: it's reasonably straightforward, meaning users can get those functions through libquadmath with GCC 6 in the near future. While getting *f128 functions in glibc is the desired long-term goal, (a) it also involves a long and fiddly process of design, consensus building and implementing many architecture-independent glibc patches to fully support additional floating-point types in accordance with a clean agreed design, and (b) adding such functions to glibc for powerpc (as opposed to adding them for x86 / x86_64 to work out design issues) requires consensus that building glibc for powerpc can require a GCC version with support for __float128, and even if __float128 support is backported to any past release branches, I expect it will be a while before the glibc community is willing to require such a recent version (we've only today moved to requiring a minimum of GCC 4.7 to build glibc, and even that was controversial). (The libquadmath code is three years out of date with respect to glibc, which has had many relevant fixes in the past three years. You could talk to the libquadmath maintainers about getting it updated, which shouldn't be hard and should be OK while trunk is in bug-fixing mode.) -- Joseph S. Myers jos...@codesourcery.com
