On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote:
> > At the moment, GCC 12 on the server PowerPC systems supports multiple
> > 128-bit
> > floating point types:
> >
> > * _Float128 (in the C language): IEEE 128-bit floating point;
> >
> > * __float128 (in the C and C++ languages): IEEE 128-bit floating
> > point;
> >
> > * long double: One of IEEE 128-bit floating, IBM 128-bit floating
> > point,
> > or 64-bit floating point; (and)
> >
> > * __ibm128: Explicit IBM 128-bit floating point.
>
> And __ieee128, which (unlike __float128) explicitly is IEEE QP float
> (and as a bonus that is obvious in every context, too).
>
> > If a file is compiled when long double uses the IEEE 128-bit floating point
> > type, then the __float128 type is the long double type and it uses the
> > TFmode
> > mode. And while the _Float128 type is distinct from long double, it also
> > uses
> > TFmode. The __ibm128 type is distinct, and it uses IFmode.
>
> 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. But
we are stuck with moving what we have forward.
> > While things mostly work with this setup, there are some things that don't
> > work
> > as well. For example, 3 of the tests fail when you are using a system like
> > Fedora 36 where IEEE 128-bit long double is default. 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.
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, since as I've said in the past, it essentially will require
a gimple pass to determine that types are used to set the bits. Right now,
because the bits are being set because of modes used, there are false
positives. If you are volunteering to do the work go ahead.
>
> > Now, I'm working on patches to 'do the right thing':
> >
> > * Make _Float128 and __float128 always use the same distinct type
> > and
> > always use KFmode;
> >
> > * Make __ibm128 use a distinct type and always use IFmode; (and)
>
> 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.
> Please open PRs for the broken testcases (one for each, unless of course
> you are confident they are the same problems: it is much easier to join
> PRs than to split them).
Of course, but I want to scope out the work.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
