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
