https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 11 Sep 2020, segher at gcc dot gnu.org wrote: > > #ifndef RS6000_MODES_H > > #define RS6000_MODES_H 1 > > #define FLOAT_PRECISION_IFmode 128 > > #define FLOAT_PRECISION_TFmode 127 > > #define FLOAT_PRECISION_KFmode 126 > > Yes, this is a useful hack, but it has its own problems; the underlying > problem *still* has to be fixed (namely, the assumption that if you have > two floating point modes, they are ordered such that any number in one of > the modes can be represented in the other. In reality no such ordering > exists: __ibm128 has values not representable in __ieee128, and vice versa). > > We do have two 16 byte floating point modes, and neither is "greater" than > the other. Closely related: the LONG_DOUBLE_TYPE_SIZE target macro which assumes "size in bits" can uniquely determine the format of long double. In the absence of hacks such as the above, LONG_DOUBLE_TYPE_SIZE needs replacing by a target hook that returns the machine mode, not "size in bits" (maybe a hook that covers all of float, double and long double).
