Whoops, I thought I was replying to the second patch about Decimal and IEEE
128-bit conversion, not about built-in support.
On Wed, Jan 27, 2021 at 10:01:38PM -0500, Michael Meissner wrote:
> On Wed, Jan 27, 2021 at 07:43:56PM -0600, Segher Boessenkool wrote:
> > 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:
> > > > November 19th, 2020:
> > > > Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>
> > >
> > > Subject and date should be sufficient
> >
> > Only if people pick good subjects, and do not send ten patches with a
> > similar subject line on the same day. I asked for the message id,
> > that works pretty much everywhere.
> >
> > > _if_ having the old versions
> > > of the patchs are necessary to review the latest version of the
> > > patch. Which ideally is not the case.
> >
> > Stronger that that: I need to know what changed! So please just explain
> > what changed, in just a short sentence or two, or more if that is needed
> > (but not if it is not needed).
>
> In the past you complained that the patch would abort if the user did not link
> against GLIBC 2.32 (because there is an #ifdef in the code to do the abort if
> gcc was configured against an older GLIBC).
>
> In addition, it used some pre-processor magic so that I didn't have to modify
> the dfp-bit.{c,h} functions to add new functions. In particular, the new
> functions pretended they where the TF functions, and used #define to change
> the
> names.
>
> The new code modifies dfp-bit.{c,h} to have support for the KF functions as
> separate #ifdef's. It eliminates the preprocessor trickery, since I did
> modify
> the dfp-bit.{c,h} support.
>
> In order to deal with older GLIBC's, I used a different function for the KF
> library (__sprintfkf instead of sprintf, and __strtokf instead of strold).
> This function uses weak references to see if we had the GLIBC symbols
> (__sprintfieee128 and __strtoieee128 that are in GLIBC 2.32). If those
> functions exist, we call those functions directly.
>
> If those functions do not exist, I converted the _Float128 type to or from
> __ibm128, and I did the normal long double conversions. Given that IEEE
> 128-bit has a much larger exponent range than IBM 128-bit, it means there are
> some numbers that can't be converted. But at least the majority of the values
> are converted.
>
> Note all of the other binary/decimal conversions use the GLIBC functions
> (either sprintf or strto<x>). The GLIBC people have the expertise to do the
> conversion, wheras I do not. But until GLIBC 2.32, there was not enough of
> the
> support in GLIBC to handle IEEE 128-bit conversions.
--
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
