This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH], PowerPC IEEE 128-bit patch #8 (libgcc bits)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <dje dot gcc at gmail dot com>, <sjmunroe at us dot ibm dot com>, <tulioqm at br dot ibm dot com>
- Date: Tue, 3 Nov 2015 23:41:44 +0000
- Subject: Re: [PATCH], PowerPC IEEE 128-bit patch #8 (libgcc bits)
- Authentication-results: sourceware.org; auth=none
- References: <20150729200428 dot GA30347 at ibm-tiger dot the-meissners dot org> <20150814154859 dot GC20847 at ibm-tiger dot the-meissners dot org> <20151023172210 dot GA18348 at ibm-tiger dot the-meissners dot org> <20151027222704 dot GA16546 at ibm-tiger dot the-meissners dot org> <alpine dot DEB dot 2 dot 10 dot 1510272241500 dot 21730 at digraph dot polyomino dot org dot uk> <20151103221659 dot GA19985 at ibm-tiger dot the-meissners dot org>
On Tue, 3 Nov 2015, Michael Meissner wrote:
> > 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.
Thanks. Given a large, complicated series of patches like this, it's hard
to have confidence that the code (both in the back end and in libgcc) is
working correctly (or that back-end changes don't break it) without
building a substantial body of __float128 code (such as libquadmath) using
it.
The libquadmath maintainers had a way of hacking up the glibc libm
testsuite to use it for testing libquadmath
<https://gcc.gnu.org/ml/gcc-patches/2012-10/msg02958.html>. To use that
you'd need to take a three-year-old version of the glibc libm tests (since
they've been massively reworked since then, which would require major
reworking of the hacks), and I suppose compare the results with the
(not-clean) results for x86_64 reported in that thread, since those hacks
were never close to having clean test results (whereas the current libm
testsuite itself does produce clean results for ldbl-128 testing on
architectures using binary128 long double, given an up-to-date
libm-test-ulps file). Enabling the libm testsuite to be used cleanly for
other types would be several of the maybe 50 or more patches involved in
getting _Float128 support into glibc (which might have the side-effect of
facilitating libquadmath updates and testing).
--
Joseph S. Myers
joseph@codesourcery.com