On Wed, Aug 10, 2022 at 02:23:27AM -0400, Michael Meissner wrote: > On Fri, Aug 05, 2022 at 01:19:05PM -0500, Segher Boessenkool wrote: > > On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote: > > > These patches lay the foundation for a set of follow-on patches that will > > > change the internal handling of 128-bit floating point types in GCC. In > > > the > > > future patches, I hope to change the compiler to always use KFmode for the > > > explicit _Float128/__float128 types, to always use TFmode for the long > > > double > > > type, no matter which 128-bit floating point type is used, and IFmode for > > > the > > > explicit __ibm128 type. > > > > Making TFmode different from KFmode and IFmode is not an improvement. > > NAK. > > First of all, it already IS different from KFmode and IFmode, as we've talked > about.
It always is the same as either IFmode or KFmode in the end. It is a separate mode, yes, because generic code always wants to use TFmode. > I'm trying to clean this mess up. Having explicit __float128's being > converted to TFmode if -mabi=ieeelongdouble is just as bad, and it means that > _Float128 and __float128 are not the same type. What do types have to do with this at all? If TFmode means IEEE QP float, TFmode and KFmode can be used interchangeably. When TFmode means double-double, TFmode and IFmode can be used interchangeably. We should never depend on TFmode being different from both underlying modes, that way madness lies. If you remember, in 2016 or such I experimented with making TFmode a macro-like thingie, so that we always get KFmode and IFmode in the instruction stream. This did not work because of the fundamental problem that KFmode and IFmode cannot be ordered: for both modes there are numbers it can represent that cannot be represented in the other mode; converting from IFmode to KFmode is lossty for some numbers, and the same is true for converting from KFmode to IFmode. But, some internals of GCC require all pairs of floating point modes (that can be converted between at least) to be comparable (in the mathmatical sense). Until that problem is solved, we CANNOT move forward. Your 126/127/128 precision hack gave us some time, but nothing has been improved since then, and things have started to fall apart at the seams again Segher
