On 8/10/21 2:29 AM, Tobias Burnus wrote:
[snip]
OK. I now think it's correct that the Fortran front end doesn't
support c_float128 and c_float128_complex on this target, but that the
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,
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).
As written above, there is nothing in Fortran (the language) which
prevents those to be mapped to, e.g., kind=14, 15, 16. Thus, I do not
see the conclusion that all of them would be kind=16 – neither from the
code
(which filters out all but TFmode for kind=16) nor from the language.
(On the other hand, support for multiple 128bit FP is also not in the FE
- nor
the support for real kind != 4,8,10,16.)
Just to quickly address this one point:
It's not in Fortran (the language), but gfc_init_kinds says:
/* Let the kind equal the precision divided by 8, rounding up. Again,
this insulates the programmer from the underlying byte size. [...] */
kind = (GET_MODE_PRECISION (mode) + 7) / 8;
and indeed all 3 of those modes would map onto kind 16 -- unless we want
to make some exception in the general formula, e.g. using a target hook.
I'm not terribly inclined to go down that path, myself. All I really
want to do is make c_float128 and c_float128_complex get defined
properly for the types Fortran already supports.
I need to think some more about your other comments but I'll try to come
up with a revised patch to address them.
-Sandra
