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: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
