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
