[Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

Sandra Loosemore sandra@codesourcery.com
Tue Aug 10 15:58:21 GMT 2021

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.


More information about the Gcc-patches mailing list