On Tue, Oct 27, 2015 at 11:38:48PM +0000, Joseph Myers wrote:
> 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.
Just to update you. Tulio and Steve have been working on patches to include
exception support. I will be submitting revised patches once things settle
down. Note, Tulio will be on vacation for the next 2 weeks.
We also will be eliminating the __cmp{o,u}kf2 functions, and go back to the
__eqkf2, etc. like the other software emulation patches. It isn't as simple to
just eliminate the define insn for cbranch... for the KFmodes, as it will
convert KFmode to TFmode and do that comparison. I will be working on that,
along with the other non-IEEE work for GCC 6.
> 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.
Ok.
> 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.)
That fell through the cracks. Thanks.
> 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.
The intention was to keep those to allow other compilers (XL, LLVM) to use
these functions for developing their own IEEE 128-bit support. However, since
I posted the patch, those groups feel they cannot use the libgcc support due to
GPL licensing issues.
Since we will be returning to use those functions, I will eliminate the cmp*
file.
> 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 thought I had listed them. Thanks.
> 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.
Yes, I plan to do that once the basic support is in.
> /* { 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.)
I haven't gotten to the builtin functions yet. Those are a reasonable start.
> 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).
Once the basic support is in, I was planning on looking at what is needed with
libquadmath.
> 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.)
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
