On Wed, Jan 27, 2021 at 01:06:46PM -0600, will schmidt wrote:
> On Thu, 2021-01-14 at 11:59 -0500, Michael Meissner via Gcc-patches wrote:
> > From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
> > From: Michael Meissner <meiss...@linux.ibm.com>
> > Date: Wed, 13 Jan 2021 21:47:03 -0500
> > Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.
> >
> > This patch replaces patches previously submitted:
> >
> > September 24th, 2020:
> > Message-ID: <20200924203159.ga31...@ibm-toto.the-meissners.org>
> >
> > October 9th, 2020:
> > Message-ID: <20201009043543.ga11...@ibm-toto.the-meissners.org>
> >
> > October 24th, 2020:
> > Message-ID: <20201022220346.ga8...@ibm-toto.the-meissners.org>
> >
> > November 19th, 2020:
> > Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
>
>
> Subject and date should be sufficient _if_ having the old versions
> of the patchs are necessary to review the latest version of the
> patch. Which ideally is not the case.
>
>
> >
> > This patch maps the built-in functions that take or return long double
> > arguments on systems where long double is IEEE 128-bit.
> >
> > If long double is IEEE 128-bit, this patch goes through the built-in
> > functions
> > and changes the name of the math, scanf, and printf built-in functions to
> > use
> > the functions that GLIBC provides when long double uses the IEEE 128-bit
> > representation.
>
> ok.
>
> >
> > In addition, changing the name in GCC allows the Fortran compiler to
> > automatically use the correct name.
>
> Does the fortran compiler currently use the wrong name? (pr?)
Yes. If the compiler is configured for IBM 128-bit long double, the Fortran
compiler calls 'sinl' for real*16. If the compiler is configured for IEEE
128-bit long double, the compiler needs to call __sinieee128 instead of sinl.
Similarly if a C or C++ user calls __builtin_sinl directly without including
math.h, the wrong name would be used.
Hence what this code does is change the names of all of the built-in functions
that can use long double to be the names appropriate for IEEE 128-bit.
> >
> > To map the math functions, typically this patch changes <name>l to
> > __<name>ieee128. However there are some exceptions that are handled with
> > this
> > patch.
>
> This appears to be the rs6000_mangle_decl_assembler_name() function, which
> also maps <name>l_r to <name>ieee128_r, and looks like some additional special
> handling for printf and scanf.
Yes, the rs6000_mangle_decl_assembler_name was not complete in the mapping. In
particular, it did not handle *printf, *scanf, or *l_r calls. There are also a
few names that need to have a different mapping.
>
> > To map the printf functions, <name> is mapped to __<name>ieee128.
> >
> > To map the scanf functions, <name> is mapped to __isoc99_<name>ieee128.
>
>
> >
> > I have tested this patch by doing builds, bootstraps, and make check with 3
> > builds on a power9 little endian server:
> >
> > * Build one used the default long double being IBM 128-bit;
> > * Build two set the long double default to IEEE 128-bit; (and)
> > * Build three set the long double default to 64-bit.
> >
>
> ok
>
> > The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
> > appropriate long double options.
>
> Presumably the build is otherwise broken...
> Does that mean more than invoking download_preqrequisites as part of the
> build? If there are specific options required during configure/build of
> those packages, they should be called out.
>
> > There were a few differences in the test
> > suite runs that will be addressed in later patches, but over all it works
> > well.
>
> Presumably minimal. :-)
It depends on what you mean by minimal.
* There are 5 C tests that fail (2 Decimal/IEEE, 3 NaN related)
* 2 C tests that need some changes to be able to run
* There are 2 C++ tests that fail (Decimal/IEEE, same as the C tests)
* There are 31 C++ modules tests that fail (PR 98645)
* There are 3 Fortran tests that used to fail that now pass
I have patches for the Decimal/IEEE tests
>
> > This patch is required to be able to build a toolchain where the
> > default
> > long double is IEEE 128-bit.
>
> Ok. Could lead the patch description with this,. I imagine this is
> just one of several patches that are still required towrards that goal.
In terms of 'need', this patch and the Decimal patch next are the two patches
that absolutely need to be installed. The others fix some things and tests,
but are not required.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
