Resend: Potential upcoming changes in mangling to PowerPC GCC
Segher Boessenkool
segher@kernel.crashing.org
Wed Aug 10 17:14:45 GMT 2022
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
More information about the Libc-alpha
mailing list