[PATCH, V2] Add conversions between _Float128 and Decimal.

[Segher Boessenkool]

On Mon, Feb 22, 2021 at 03:52:52PM -0500, Michael Meissner wrote:
> On Sat, Feb 20, 2021 at 06:33:12PM -0600, Segher Boessenkool wrote:
> > So if built with a glibc version before 2.32 (less than a year old) it
> > will give the wrong answer.  This needs improving, or it will be another
> > eight or so years until this is generally usable.
> 
> But until the long double format default is changed to be IEEE 128-bit floating
> point,  only the people who explicitly convert between __float128/_Float128 and
> the decimal types will see the issue.
> 
> In order to switch to the IEEE 128-bit floating point long double, you need at
> least GLIBC 2.32, and you will get full accuracy.

But see my point.  It only works if you can break all links with the
past.  Which cannot work if you have to work together with other
communities, don't just do your own thing.

("Full accuracy" is a strange thing to say...  doubele-double has (much)
higher precision for some numbers...  but if you want IEEE float
semantics, double-double is simply *wrong*).

> > > The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
> > > appropriate long double options.  There were a few differences in the test
> > > suite runs that will be addressed in later patches, but over all it works
> > > well.
> > 
> > What kind of differences?  I assume you checked all, and all differences
> > are an improvement, or the differences are inconsequential and the test
> > is not very good?
> 
> I have submitted patches for these before, and I will shortly ping or resubmit
> them again.  But I felt this was more import to get in before worrying about
> changes to the testsuite.

That isn't what I asked?  I don't want to investigate all these bugs, I
just asked if you did and found nothing that should hold up this patch.
Just "yes" would work :-)

> The following two tests fail because they are testing the old libquadmath 'q'
> built-ins, and there is a subtle difference between using the _Float128
> built-in function for the nans function and the long double built-in function
> for nans.  In particular, the signalling NaN is silently converted to a quiet
> NaN.
> 
>     * gcc.dg/torture/float128-nan.c
>     * gcc.target/powerpc/nan128-1.c

Both tests needs to use -fsignaling-nans.  Do they work better with that
fixed?

> > > +_Float128
> > > +__strtokf (const char *string, char **endptr)
> > > +{
> > > +  long double num;
> > > +
> > > +  if (__strtoieee128)
> > > +    return __strtoieee128 (string, endptr);
> > > +
> > > +  num = strtold (string, endptr);
> > > +  return (_Float128) num;
> > 
> > Do not cast return values please.  All casts you do should be *needed*,
> > have a purpose.
> 
> Well it is changing type (num is long double, i.e. IBM 128-bit long double) and
> the return is _Float128.

And this does not make a difference since function prototypes exist.  So
please don't.  *All* casts there are should be there for a reason; and
the few casts you end up using all look like a "danger!" sign to a
careful reader (they hide compiler warnings, and that is the *least*
trouble they cause!)


Thanks,


Segher