Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

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

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