Re: PowerPC: Add __float128 conversions to/from Decimal
On Thu, Oct 29, 2020 at 10:05:38PM +, Joseph Myers wrote: > On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > > > Doing these conversions accurately is nontrivial. Converting via strings > > > is the simple approach (i.e. the one that moves the complexity somewhere > > > else). There are more complicated but more efficient approaches that can > > > achieve correct conversions with smaller bounds on resource usage (and > > > there are various papers published in this area), but those involve a lot > > > more code (and precomputed data, with a speed/space trade-off in how much > > > you precompute; the BID code in libgcc has several MB of precomputed data > > > for that purpose). > > > > Does the printf code in libgcc handle things correctly for IEEE QP float > > as long double, do you know? > > As far as I know, the code in libgcc for conversions *from* decimal *to* > binary (so the direction that uses strtof128 as opposed to the one using > strfrom128, in the binary128 case) works correctly, if the underlying libc > has accurate string/numeric conversion operations. > > Binary to decimal is another matter, even for cases such as float to > _Decimal64. I've just filed bug 97635 for that. > > Also note that if you want to use printf as opposed to strfromf128 for > IEEE binary128 you'll need to use __printfieee128 (the version that > expects long double to be IEEE binary128) which was introduced in glibc > 2.32, so that doesn't help with the glibc version dependencies. My latest patches now switches to using the GLIBC 2.32 and __sprintfieee128. If we don't have glibc 2.32, it just calls abort, so we don't get linker errors. I hope to submit it tonight or tomorrow night. > When I investigated and reported several bugs in the conversion operations > in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that > the libgcc versions were working correctly for those tests (and filed and > subsequently fixed one glibc strtod bug, missing inexact exceptions, that > I'd noticed while looking at such issues in libdfp). But the specific > case I tested for badly rounded conversions was the case of conversions > from decimal to binary, not the case of conversions from binary to > decimal, which, as noted above, turn out to be buggy in libgcc. > > Lots of bugs have been fixed in the glibc conversion code over the years > (more on the strtod side than in the code shared by printf and strfrom > functions). That code uses multiple-precision operations from GMP, which > avoids some complications but introduces others (it also needs to e.g. > deal with locale issues, which are irrelevant for libgcc conversions). Using the sprintf method, I see an error in c-c++-common/dfp/convert-bfp-11.c that I didn't see with the method used in the patches with strtof128 and strfromf128 directly. I need to track down exactly what the error is. All of the other dfp conversion tests work fine. -- 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
Re: PowerPC: Add __float128 conversions to/from Decimal
On Tue, Nov 03, 2020 at 01:12:29AM +, Joseph Myers wrote: > On Mon, 2 Nov 2020, Segher Boessenkool wrote: > > > > Also note that if you want to use printf as opposed to strfromf128 for > > > IEEE binary128 you'll need to use __printfieee128 (the version that > > > expects long double to be IEEE binary128) which was introduced in glibc > > > 2.32, so that doesn't help with the glibc version dependencies. > > > > libiberty has printf functions of its own, I was wondering if those work > > fine; if they do, that would solve all problems here. > > I don't see any meaningful kind of printf implementation in libiberty. > There are implementations of various printf functions in terms of other > printf functions (including vprintf in terms of vfprintf in terms of > _doprnt in terms of fprintf), but nothing that actually does the main work > of converting a floating-point value to a string without calling out to > some libc printf function. I missed that "in terms of fprintf" step :-( Well, rats. Thanks for telling me about my stupidity! :-) Segher
Re: PowerPC: Add __float128 conversions to/from Decimal
On Mon, 2 Nov 2020, Segher Boessenkool wrote: > > Also note that if you want to use printf as opposed to strfromf128 for > > IEEE binary128 you'll need to use __printfieee128 (the version that > > expects long double to be IEEE binary128) which was introduced in glibc > > 2.32, so that doesn't help with the glibc version dependencies. > > libiberty has printf functions of its own, I was wondering if those work > fine; if they do, that would solve all problems here. I don't see any meaningful kind of printf implementation in libiberty. There are implementations of various printf functions in terms of other printf functions (including vprintf in terms of vfprintf in terms of _doprnt in terms of fprintf), but nothing that actually does the main work of converting a floating-point value to a string without calling out to some libc printf function. -- Joseph S. Myers jos...@codesourcery.com
Re: PowerPC: Add __float128 conversions to/from Decimal
Hi Joseph, On Thu, Oct 29, 2020 at 10:05:38PM +, Joseph Myers wrote: > On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > > Doing these conversions accurately is nontrivial. Converting via strings > > > is the simple approach (i.e. the one that moves the complexity somewhere > > > else). There are more complicated but more efficient approaches that can > > > achieve correct conversions with smaller bounds on resource usage (and > > > there are various papers published in this area), but those involve a lot > > > more code (and precomputed data, with a speed/space trade-off in how much > > > you precompute; the BID code in libgcc has several MB of precomputed data > > > for that purpose). > > > > Does the printf code in libgcc handle things correctly for IEEE QP float > > as long double, do you know? > > As far as I know, the code in libgcc for conversions *from* decimal *to* > binary (so the direction that uses strtof128 as opposed to the one using > strfrom128, in the binary128 case) works correctly, if the underlying libc > has accurate string/numeric conversion operations. > > Binary to decimal is another matter, even for cases such as float to > _Decimal64. I've just filed bug 97635 for that. > > Also note that if you want to use printf as opposed to strfromf128 for > IEEE binary128 you'll need to use __printfieee128 (the version that > expects long double to be IEEE binary128) which was introduced in glibc > 2.32, so that doesn't help with the glibc version dependencies. libiberty has printf functions of its own, I was wondering if those work fine; if they do, that would solve all problems here. > When I investigated and reported several bugs in the conversion operations > in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that > the libgcc versions were working correctly for those tests (and filed and > subsequently fixed one glibc strtod bug, missing inexact exceptions, that > I'd noticed while looking at such issues in libdfp). But the specific > case I tested for badly rounded conversions was the case of conversions > from decimal to binary, not the case of conversions from binary to > decimal, which, as noted above, turn out to be buggy in libgcc. Yeah :-( > Lots of bugs have been fixed in the glibc conversion code over the years > (more on the strtod side than in the code shared by printf and strfrom > functions). That code uses multiple-precision operations from GMP, which > avoids some complications but introduces others (it also needs to e.g. > deal with locale issues, which are irrelevant for libgcc conversions). Thanks for the info, Segher
Re: PowerPC: Add __float128 conversions to/from Decimal
On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > Doing these conversions accurately is nontrivial. Converting via strings > > is the simple approach (i.e. the one that moves the complexity somewhere > > else). There are more complicated but more efficient approaches that can > > achieve correct conversions with smaller bounds on resource usage (and > > there are various papers published in this area), but those involve a lot > > more code (and precomputed data, with a speed/space trade-off in how much > > you precompute; the BID code in libgcc has several MB of precomputed data > > for that purpose). > > Does the printf code in libgcc handle things correctly for IEEE QP float > as long double, do you know? As far as I know, the code in libgcc for conversions *from* decimal *to* binary (so the direction that uses strtof128 as opposed to the one using strfrom128, in the binary128 case) works correctly, if the underlying libc has accurate string/numeric conversion operations. Binary to decimal is another matter, even for cases such as float to _Decimal64. I've just filed bug 97635 for that. Also note that if you want to use printf as opposed to strfromf128 for IEEE binary128 you'll need to use __printfieee128 (the version that expects long double to be IEEE binary128) which was introduced in glibc 2.32, so that doesn't help with the glibc version dependencies. When I investigated and reported several bugs in the conversion operations in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that the libgcc versions were working correctly for those tests (and filed and subsequently fixed one glibc strtod bug, missing inexact exceptions, that I'd noticed while looking at such issues in libdfp). But the specific case I tested for badly rounded conversions was the case of conversions from decimal to binary, not the case of conversions from binary to decimal, which, as noted above, turn out to be buggy in libgcc. Lots of bugs have been fixed in the glibc conversion code over the years (more on the strtod side than in the code shared by printf and strfrom functions). That code uses multiple-precision operations from GMP, which avoids some complications but introduces others (it also needs to e.g. deal with locale issues, which are irrelevant for libgcc conversions). -- Joseph S. Myers jos...@codesourcery.com
Re: PowerPC: Add __float128 conversions to/from Decimal
On Thu, Oct 29, 2020 at 06:31:54PM +, Joseph Myers wrote: > On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > > > +#if HAVE_KF_MODE > > > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > > > +#else > > > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > > > > > +#endif > > > > > > > > Does strfromf128 exist everywhere we build this? It isn't a standard > > > > function. > > > > > > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes > > > most of > > > the *f128 functions. > > > > But this means it does *not* exist most places we build this? Not the > > whole world is Linux (and even then, it is probably a too recent > > addition). > > strfromf128 and strtof128 were added for powerpc64le-linux-gnu in glibc > 2.26. (The variants that are namespace-clean in the absence of 18661-3, > which may be relevant when being used for long double, __strfromieee128 > and __strtoieee128, were added in 2.32.) And we otherwise support at least glibc 2.17 still (that is what RHEL 7 has). > Doing these conversions accurately is nontrivial. Converting via strings > is the simple approach (i.e. the one that moves the complexity somewhere > else). There are more complicated but more efficient approaches that can > achieve correct conversions with smaller bounds on resource usage (and > there are various papers published in this area), but those involve a lot > more code (and precomputed data, with a speed/space trade-off in how much > you precompute; the BID code in libgcc has several MB of precomputed data > for that purpose). Does the printf code in libgcc handle things correctly for IEEE QP float as long double, do you know? Segher
Re: PowerPC: Add __float128 conversions to/from Decimal
On Thu, 29 Oct 2020, Segher Boessenkool wrote: > Hi! > > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > > +#if HAVE_KF_MODE > > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > > +#else > > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > > > > +#endif > > > > > > Does strfromf128 exist everywhere we build this? It isn't a standard > > > function. > > > > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most > > of > > the *f128 functions. > > But this means it does *not* exist most places we build this? Not the > whole world is Linux (and even then, it is probably a too recent > addition). strfromf128 and strtof128 were added for powerpc64le-linux-gnu in glibc 2.26. (The variants that are namespace-clean in the absence of 18661-3, which may be relevant when being used for long double, __strfromieee128 and __strtoieee128, were added in 2.32.) Doing these conversions accurately is nontrivial. Converting via strings is the simple approach (i.e. the one that moves the complexity somewhere else). There are more complicated but more efficient approaches that can achieve correct conversions with smaller bounds on resource usage (and there are various papers published in this area), but those involve a lot more code (and precomputed data, with a speed/space trade-off in how much you precompute; the BID code in libgcc has several MB of precomputed data for that purpose). -- Joseph S. Myers jos...@codesourcery.com
Re: PowerPC: Add __float128 conversions to/from Decimal
Hi! On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > +#if HAVE_KF_MODE > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > +#else > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > > > +#endif > > > > Does strfromf128 exist everywhere we build this? It isn't a standard > > function. > > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most of > the *f128 functions. But this means it does *not* exist most places we build this? Not the whole world is Linux (and even then, it is probably a too recent addition). Does it need something in libibiberty maybe? At least _doprnt handles long double (whatever type it uses for that, but that can be fixed :-) ) (_doprint is used by all the libiberty versions of the printf family, and it handles %lf etc. for long double.) > We have to use str* instead of sprintf or scanf, because I don't believe their > is a float128 format specifier. No standard one at least, yes. > > > +/* Support PowerPC KF mode, which is __float128 when long double is > > > + IBM extended double. */ > > > +#if defined (L_sd_to_kf) || defined (L_dd_to_kf) || defined (L_td_to_kf) > > > \ > > > + || defined (L_kf_to_sd) || defined (L_kf_to_dd) || defined (L_kf_to_td) > > > +#define HAVE_KF_MODE 1 > > > +#endif > > > > This might want a better name, other targets can have a KFmode as well, > > for some completely different purpose, since it is not a standard mode. > > Given everything else uses *F, including XF on the x86, I figured it was > easier > than creating a new name. I mean the name for the macro. "HAVE_KF_MODE" is not great. Anyway, some libgcc maintainer needs to review this, you may be lucky with this ;-) Segher
Re: PowerPC: Add __float128 conversions to/from Decimal
On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > On Thu, Oct 22, 2020 at 06:06:03PM -0400, Michael Meissner wrote: > > This patch adds the various decimal to/from IEEE 128-bit conversions. I > > had to make some changes to the infrastructure, since that infrastructure > > assumed that there is a sprintf/scanf format modifier to convert floating > > point. Instead, I used to str* conversion functions. > > > --- /dev/null > > +++ b/libgcc/config/rs6000/_dd_to_kf.c > > > +/* Decimal64 -> _Float128 conversion. */ > > +#define FINE_GRAINED_LIBRARIES 1 > > This isn't defined in any other source file (instead, it is put in the > Makefile). Why should it be different here? I'll check it out. > > +# Force the TF mode to/from decimal functions to be compiled with IBM long > > +# double. Add building the KF mode to/from decimal conversions with > > explict > > (typo, "explicit") > > > +#if HAVE_KF_MODE > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > +#else > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > > +#endif > > Does strfromf128 exist everywhere we build this? It isn't a standard > function. Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most of the *f128 functions. We have to use str* instead of sprintf or scanf, because I don't believe their is a float128 format specifier. > > +/* Support PowerPC KF mode, which is __float128 when long double is > > + IBM extended double. */ > > +#if defined (L_sd_to_kf) || defined (L_dd_to_kf) || defined (L_td_to_kf) \ > > + || defined (L_kf_to_sd) || defined (L_kf_to_dd) || defined (L_kf_to_td) > > +#define HAVE_KF_MODE 1 > > +#endif > > This might want a better name, other targets can have a KFmode as well, > for some completely different purpose, since it is not a standard mode. Given everything else uses *F, including XF on the x86, I figured it was easier than creating a new name. > (Some libgcc maintainer needs to approve the generic parts, not all of > it can obviously only trigger for us.) > > > Segher -- 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
Re: PowerPC: Add __float128 conversions to/from Decimal
On Thu, Oct 22, 2020 at 06:06:03PM -0400, Michael Meissner wrote: > This patch adds the various decimal to/from IEEE 128-bit conversions. I > had to make some changes to the infrastructure, since that infrastructure > assumed that there is a sprintf/scanf format modifier to convert floating > point. Instead, I used to str* conversion functions. > --- /dev/null > +++ b/libgcc/config/rs6000/_dd_to_kf.c > +/* Decimal64 -> _Float128 conversion. */ > +#define FINE_GRAINED_LIBRARIES 1 This isn't defined in any other source file (instead, it is put in the Makefile). Why should it be different here? > +# Force the TF mode to/from decimal functions to be compiled with IBM long > +# double. Add building the KF mode to/from decimal conversions with explict (typo, "explicit") > +#if HAVE_KF_MODE > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > +#else >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > +#endif Does strfromf128 exist everywhere we build this? It isn't a standard function. > +/* Support PowerPC KF mode, which is __float128 when long double is > + IBM extended double. */ > +#if defined (L_sd_to_kf) || defined (L_dd_to_kf) || defined (L_td_to_kf) \ > + || defined (L_kf_to_sd) || defined (L_kf_to_dd) || defined (L_kf_to_td) > +#define HAVE_KF_MODE 1 > +#endif This might want a better name, other targets can have a KFmode as well, for some completely different purpose, since it is not a standard mode. (Some libgcc maintainer needs to approve the generic parts, not all of it can obviously only trigger for us.) Segher
Re: PowerPC: Add __float128 conversions to/from Decimal
On Thu, 2020-10-22 at 18:06 -0400, Michael Meissner via Gcc-patches wrote: > PowerPC: Add __float128 conversions to/from Decimal. > > I have split all of these patches into separate patches to hopefully get them > into the tree. > > This patch adds the various decimal to/from IEEE 128-bit conversions. I > had to make some changes to the infrastructure, since that infrastructure > assumed that there is a sprintf/scanf format modifier to convert floating > point. Instead, I used to str* conversion functions. > > I have tested this patch with bootstrap builds on a little endian power9 > system > running Linux. With the other patches, I have built two full bootstrap builds > using this patch and the patches after this patch. One build used the current > default for long double (IBM extended double) and the other build switched the > default to IEEE 128-bit. I used the Advance Toolchain AT 14.0 compiler as the > library used by this compiler. There are no regressions between the tests. > There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and > default_format_denormal_2.f90) that now pass. > > Can I install this into the trunk? > > We have gotten some requests to back port these changes to GCC 10.x. At the > moment, I am not planning to do the back port, but I may need to in the > future. > > libgcc/ > 2020-10-22 Michael Meissner > > * config/rs6000/_dd_to_kf.c: New file. > * config/rs6000/_kf_to_dd.c: New file. > * config/rs6000/_kf_to_sd.c: New file. > * config/rs6000/_kf_to_td.c: New file. > * config/rs6000/_sd_to_kf.c: New file. > * config/rs6000/_td_to_kf.c: New file. > * config/rs6000/t-float128: Build __float128 conversions to and > from Decimal support functions. ok > * dfp-bit.c: Add support for building the PowerPC _Float128 > to/from Decimal conversion functions. > * dfp-bit.h: Likewise. These are non-arch, so attention to anyone who also needs to bless this generically. :-) > --- > libgcc/config/rs6000/_dd_to_kf.c | 30 ++ > libgcc/config/rs6000/_kf_to_dd.c | 30 ++ > libgcc/config/rs6000/_kf_to_sd.c | 30 ++ > libgcc/config/rs6000/_kf_to_td.c | 30 ++ > libgcc/config/rs6000/_sd_to_kf.c | 30 ++ > libgcc/config/rs6000/_td_to_kf.c | 30 ++ > libgcc/config/rs6000/t-float128 | 20 - > libgcc/dfp-bit.c | 10 +++-- > libgcc/dfp-bit.h | 37 +--- > 9 files changed, 241 insertions(+), 6 deletions(-) > create mode 100644 libgcc/config/rs6000/_dd_to_kf.c > create mode 100644 libgcc/config/rs6000/_kf_to_dd.c > create mode 100644 libgcc/config/rs6000/_kf_to_sd.c > create mode 100644 libgcc/config/rs6000/_kf_to_td.c > create mode 100644 libgcc/config/rs6000/_sd_to_kf.c > create mode 100644 libgcc/config/rs6000/_td_to_kf.c > > diff --git a/libgcc/config/rs6000/_dd_to_kf.c > b/libgcc/config/rs6000/_dd_to_kf.c > new file mode 100644 > index 000..081415fd393 > --- /dev/null > +++ b/libgcc/config/rs6000/_dd_to_kf.c > @@ -0,0 +1,30 @@ > +/* Copyright (C) 1989-2020 Free Software Foundation, Inc. Should that (new file) have the 1989 start date (since it is presumably based on an existing file), or start with 2020? Same with the others here. > + > +This file is part of GCC. > + > +GCC is free software; you can redistribute it and/or modify it under > +the terms of the GNU General Public License as published by the Free > +Software Foundation; either version 3, or (at your option) any later > +version. > + > +GCC is distributed in the hope that it will be useful, but WITHOUT ANY > +WARRANTY; without even the implied warranty of MERCHANTABILITY or > +FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > +for more details. > + > +Under Section 7 of GPL version 3, you are granted additional > +permissions described in the GCC Runtime Library Exception, version > +3.1, as published by the Free Software Foundation. > + > +You should have received a copy of the GNU General Public License and > +a copy of the GCC Runtime Library Exception along with this program; > +see the files COPYING3 and COPYING.RUNTIME respectively. If not, see > +<http://www.gnu.org/licenses/>. */ > + > +/* Decimal64 -> _Float128 conversion. */ > +#define FINE_GRAINED_LIBRARIES 1 > +#define L_dd_to_kf 1 > +#define WIDTH64 > + > +/* Use dfp-bit.c to do the real work. */ > +#include "dfp-bit.c" > diff --git a/libgcc/config/rs6000/_kf_t
PowerPC: Add __float128 conversions to/from Decimal
PowerPC: Add __float128 conversions to/from Decimal. I have split all of these patches into separate patches to hopefully get them into the tree. This patch adds the various decimal to/from IEEE 128-bit conversions. I had to make some changes to the infrastructure, since that infrastructure assumed that there is a sprintf/scanf format modifier to convert floating point. Instead, I used to str* conversion functions. I have tested this patch with bootstrap builds on a little endian power9 system running Linux. With the other patches, I have built two full bootstrap builds using this patch and the patches after this patch. One build used the current default for long double (IBM extended double) and the other build switched the default to IEEE 128-bit. I used the Advance Toolchain AT 14.0 compiler as the library used by this compiler. There are no regressions between the tests. There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and default_format_denormal_2.f90) that now pass. Can I install this into the trunk? We have gotten some requests to back port these changes to GCC 10.x. At the moment, I am not planning to do the back port, but I may need to in the future. libgcc/ 2020-10-22 Michael Meissner * config/rs6000/_dd_to_kf.c: New file. * config/rs6000/_kf_to_dd.c: New file. * config/rs6000/_kf_to_sd.c: New file. * config/rs6000/_kf_to_td.c: New file. * config/rs6000/_sd_to_kf.c: New file. * config/rs6000/_td_to_kf.c: New file. * config/rs6000/t-float128: Build __float128 conversions to and from Decimal support functions. * dfp-bit.c: Add support for building the PowerPC _Float128 to/from Decimal conversion functions. * dfp-bit.h: Likewise. --- libgcc/config/rs6000/_dd_to_kf.c | 30 ++ libgcc/config/rs6000/_kf_to_dd.c | 30 ++ libgcc/config/rs6000/_kf_to_sd.c | 30 ++ libgcc/config/rs6000/_kf_to_td.c | 30 ++ libgcc/config/rs6000/_sd_to_kf.c | 30 ++ libgcc/config/rs6000/_td_to_kf.c | 30 ++ libgcc/config/rs6000/t-float128 | 20 - libgcc/dfp-bit.c | 10 +++-- libgcc/dfp-bit.h | 37 +--- 9 files changed, 241 insertions(+), 6 deletions(-) create mode 100644 libgcc/config/rs6000/_dd_to_kf.c create mode 100644 libgcc/config/rs6000/_kf_to_dd.c create mode 100644 libgcc/config/rs6000/_kf_to_sd.c create mode 100644 libgcc/config/rs6000/_kf_to_td.c create mode 100644 libgcc/config/rs6000/_sd_to_kf.c create mode 100644 libgcc/config/rs6000/_td_to_kf.c diff --git a/libgcc/config/rs6000/_dd_to_kf.c b/libgcc/config/rs6000/_dd_to_kf.c new file mode 100644 index 000..081415fd393 --- /dev/null +++ b/libgcc/config/rs6000/_dd_to_kf.c @@ -0,0 +1,30 @@ +/* Copyright (C) 1989-2020 Free Software Foundation, Inc. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify it under +the terms of the GNU General Public License as published by the Free +Software Foundation; either version 3, or (at your option) any later +version. + +GCC is distributed in the hope that it will be useful, but WITHOUT ANY +WARRANTY; without even the implied warranty of MERCHANTABILITY or +FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +for more details. + +Under Section 7 of GPL version 3, you are granted additional +permissions described in the GCC Runtime Library Exception, version +3.1, as published by the Free Software Foundation. + +You should have received a copy of the GNU General Public License and +a copy of the GCC Runtime Library Exception along with this program; +see the files COPYING3 and COPYING.RUNTIME respectively. If not, see +<http://www.gnu.org/licenses/>. */ + +/* Decimal64 -> _Float128 conversion. */ +#define FINE_GRAINED_LIBRARIES 1 +#define L_dd_to_kf 1 +#define WIDTH 64 + +/* Use dfp-bit.c to do the real work. */ +#include "dfp-bit.c" diff --git a/libgcc/config/rs6000/_kf_to_dd.c b/libgcc/config/rs6000/_kf_to_dd.c new file mode 100644 index 000..09a62cbe629 --- /dev/null +++ b/libgcc/config/rs6000/_kf_to_dd.c @@ -0,0 +1,30 @@ +/* Copyright (C) 1989-2020 Free Software Foundation, Inc. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify it under +the terms of the GNU General Public License as published by the Free +Software Foundation; either version 3, or (at your option) any later +version. + +GCC is distributed in the hope that it will be useful, but WITHOUT ANY +WARRANTY; without even the implied warranty of MERCHANTABILITY or +FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +for more details. + +Under Section 7 of GPL version 3, you are granted additional +permissions described in the