[PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions.

[Michael Meissner]

On Tue, Mar 02, 2021 at 03:53:06PM -0600, Segher Boessenkool wrote:
> If you want to make decimal and/or QP float work only on 64-bit LE Linux
> you should say so.  And in that case, that is certainly not acceptable
> if it doesn't "sorry" at configure time already.

Well in general the only supported configuration for _Float128 is 64-bit LE
Linux, but this is more due to the infrastructure not supporting it.

If you want to support _Float128 on big endian, you need a GLIBC that provides
the necessary support.  As far as I know, GLIBC does not build the _Float128
support on big endian.

You also need to set the minimum CPU to power7, because _Float128 is passed in
Altivec registers.  I think some of the configure tests use the default cpu
used in building GCC (i.e. power4 if you don't use --with-cpu).

As we have discussed many times, on 32-bit BE, you cannot use hardware
_Float128 support on power9/power10 because there is no TImode in 32-bit.
Various machine independent parts of GCC require an integer type to be the same
size as basic types.  If somebody made TImode work, we can remove the
restriction and allow _Float128 to work on 32-bit.

With the current compiler on BE, if you use -mcpu=power7 or newer, it will
enable the _Float128/__float128 keywords, and generate the code.  But until
there is an expectation of library support, it won't work for the general
user.

> > The second is whether you get an error at link time because there is not
> > sprintf or strtold functions.  For normal archive libraries, this would only be
> > an issue if you actually do the conversion.  I have my doubts whether there is
> > any extant code that wants to convert _Float128 to one of the Decimal types or
> > vice versa.
> 
> So what are these patches for at all, again?

The whole reason for the patches is to provide the support when we flip the
default long double type from the IBM 128-bit type to the IEEE 128-bit type
that conversions between long double and the Decimal types will succeed.  I
suspect in real life it won't be an issue, since Decimal is not used that
much.  But it is more likely people will want to convert between binary long
double and Decimal128.

I missed the fact that it had hidden dependencies for cross compilers.  So I am
trying to fix this.

> Anyway, if some conversion doesn't work (or cannot work correctly at
> all, which is the same thing), you should simply disable the conversion
> routines themselves (and then cascade that through the possible callers:just make them say "sorry, unimplemented").
> 
> > Note the second issue would affect x86_64 cross compilers as well, since they
> > use those two functions to do the _Float128/Decimal versions.
> 
> Yes, it cannot work correctly at all there, either.

If you remember, the original versions of the patch would only work if you
configured the compiler to use GLIBC 2.32 or newer (such as using the
--with-advance-toolchain at14.0 option).  You did not like this because as you
pointed out, you might use a different GLIBC when linking.

So I wrote the current patch that uses weak references to see if we did link
with GLIBC 2.32.  If the library is present, we use the functions in that
library.  If not, we have to give an approximate answer.  I used the existing
IBM 128-bit support to do the conversion.

Given GLIBC 2.32 is the minimum version of GLIBC that supports IEEE 128-bit
long doubles, if you link against an earlier library, you will not get the
conversions from long double.  You will only get the conversion if you
explicitly use _Float128.

> > I am open to suggestions of how to move forward.  I think we have to have a way
> > to build cross compilers without decimal support (i.e. my third patch).
> > Secondarily, I think we should allow the compiler to be built if there is no
> > stdio.h, but the user did not disable decimal floating point.
> 
> Yes.  So just do not use it then.  Disable the feature that would use it.
>
> > I don't think rewriting the Decimal conversions not to use GLIBC is really
> > practical.
> 
> It is necessary if you want to support it on any other systems than the
> one you use.

Sure, but it is a massive amount of work.  And I don't have the necessary
skills to insure that the conversion process will not suffer from errors.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797