Hi! On Tue, Aug 10, 2021 at 10:29:08AM +0200, Tobias Burnus wrote: > On 09.08.21 23:42, Sandra Loosemore wrote: > In terms of Fortran, REAL types do not need to follow IEEE > (there are IEEE intrinsic modules to handle IEEE); thus, REAL(16) > does not need to be an IEEE type – albeit most users implicitly > expect it. > > Likewise, kind numbers have no meaning, but there is plenty of > code which expects that kind=4 = 32bit and kind=8 = 64bit, > especially when used in older code as '<type>*<kind>' (e.g. 'real*8') > but also quite some code using the newer syntax '<type>(<kind>)' or > '<type>(kind=<kind>') (e.g. 'real(8)' or 'real(kind=8)'). > > For real, kind=10 (i387's 80bit type) is a specialty of gfortran > (most? all?) other compilers do not support it; kind=16 is more widely > supported, albeit some simply map it to 'long double'.
So, make 16 always mean IEEE QP float for us, and 15 mean double-double? (Or whatever other number you prefer -- as you explain, 16 should be the preferred one though, and that is the IEEE float of course). > There is no reason why the different PowerPC TF modes couldn't be > mapped to, e.g., the kinds 17, 18, 19, 20 – except that the Fortran FE, > libgfortran current assumes that only 4, 8, 10 and 16 exist and if > 10 exists, 16 is the 'q'/libquadmath version. – Additionally, those > 17-20 kinds will also confuse users and using '16' has to be mapped > somehow to one of the TF modes in a way that it still works with > interface kind checks and .mod module files and PowerPC's -m flags. There are only two 16-byte float modes: IFmode is double-double, and KFmode is IEEE QP float. Those modes mean the same thing whatever options the compiler has, and whatever the default is. TFmode is another name for one of those two modes, and that one can vary. Also, of course, a mode is not a type, and a type is not a mode, they are different concepts. IEEE QP float is always available (if enabled) via __ieee128, and double-double is always available via __ibm128. > >code that initializes those constants is still buggy. The reason why > >it shouldn't support them is that all 3 128-bit floating-point modes > >on PowerPC would map onto kind=16, So fix that? 16 should be the IEEE kind, and then something else for the double-double kind? > Side note: in rs6000-modes.h, there is: > #define FLOAT_PRECISION_IFmode 128 > #define FLOAT_PRECISION_TFmode 127 > #define FLOAT_PRECISION_KFmode 126 > with IFmode (IBM 128-bit floating point), TFmode (long double mode), KFmode > (explicit __float128). This is a workaround for a fundamental problem in GCC internals, which requires all floating point modes to be ordered. This is not true for QP float and double-double: each of those can represent values the other can not. And it is only a workaround, and it will change some day. > >and we can only support one of them unless we make some exception to > >the formula for mapping precision -> kind. And the mode the Fortran > >front end already prefers is the one that corresponds to long double > >or TFmode. > I concur. A kind number should always map to the same floating point format, it should not depend on unrelated compiler flags. It should not matter at all what "long double" maps to. Anything else leads to more insanity than needed. Segher
