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

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Wed, Mar 03, 2021 at 02:12:56PM -0500, Michael Meissner wrote:
> 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.

This isn't the point.  You make it harder to support in the future, for
no reason (except a little convenience now).

> You also need to set the minimum CPU to power7, because _Float128 is passed in
> Altivec registers.

Yes, another unnecessary big restriction.

> 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.

That is a) another thing that needs fixing, and b) you *can* have
floating point modes of a size that does not exist as integer mode.

> Various machine independent parts of GCC require an integer type to be the same
> size as basic types.

And now explain float80 and float96?

> 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.

So?  That does not mean you can break it further!

> > > 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.

It has nothing to do with me liking or not liking a patch.  You are
piling on more and more dependencies, when we cannot have any.  *That*
is the problem.  And it is a *problem*.

If we have a maze of limited situations that do and don't work, testing
becomes impossible already, let alone all further support.


Segher