On Mon, Aug 08, 2022 at 05:44:36PM -0400, Michael Meissner wrote: > On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote: > > On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote: > > It would be a lot simpler and less roundabout and inside out if we could > > do this the other way around: start with the QP float and double-double > > types and modes, and point the long double type and TFmode at that. But > > alas. > > Yes if we could go back 5 years it would have been simpler to do that way.
It does not require time machines: we can change the current code *now*. > > > These 3 tests use the > > > 'nanqs' built-in function, which is mapped to 'nanf128s' and it delivers a > > > _Float128 signaling NaN. But since __float128 uses a different type, the > > > signaling NaN is converted and it loses the signaling property. > > > > So you are saying __float128 and _Float128 should *not* be separate > > types? Or, the testcases are buggy, make unwarranted assumptions? > > I am saying right now, they are separate types when -mabi=ieeelongdouble is > used. They are the same type when -mabi=ibmlongdouble is used. I think they > should be the same type, no matter which way long double is defined. Ah, good. > But there are a bunch of assumptions within the compiler that need to be > changed due to these assumptions. > > > In addition, it would be nice if we could refine the setting of bits in > > > the ELF > > > header so that if you pass an explicit __float128 or __ibm128 object, it > > > doesn't set the bits that you used long double of the appropriate type. > > > But > > > the code that sets these bits is done in the RTL stages, and it only > > > looks at > > > modes, not at types. > > > > So fix that? It is a clear bug. > > It isn't so simple, Yes it is. It *is* a clear bug. Solving it might be some work, but it has to be done, it can not be avoided. > > It cannot always use IFmode? Generic code uses TFmode for long double > > (which can be double-double). > > My point is __ibm128 can potentionally be separate and always use IFmode. > Hence my question. It cannot be. Generic code (on double-double configs) uses TFmode. It is a good idea for us to use IFmode in the backend code, certainly. Segher
