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

Sandra Loosemore sandra@codesourcery.com
Wed Aug 4 20:14:07 GMT 2021

I was trying last week to run my not-yet-committed TS29113 testsuite on 
a powerpc64le-linux-gnu target and ran into some problems with the kind 
constants c_float128 and c_float128_complex from the ISO_C_BINDING 
module; per the gfortran manual they are supposed to represent the kind 
of the gcc extension type __float128 and the corresponding complex type. 
  They were being set to -4 (e.g., not supported) instead of 16, 
although this target does define __float128 and real(16) is accepted as 
a supported type by the Fortran front end.

Anyway, the root of the problem is that the definition of these 
constants only looked at gfc_float128_type_node, which only gets set if 
TFmode is not the same type as long_double_type_node.  I experimented 
with setting gfc_float128_type_node = long_double_type_node but that 
caused various Bad Things to happen elsewhere in code that expected them 
to be distinct types, so I ended up with this minimally intrusive patch 
that only tweaks the definitions of the c_float128 and 
c_float128_complex constants.

I'm not sure this is completely correct, though.  I see PowerPC
supports 2 different 128-bit encodings and it looks like TFmode/long 
double is mapped onto the one selected by the ABI and/or command-line 
options; that's the only one the Fortran front end knows about.  All of 
TFmode, IFmode, and KFmode would map onto kind 16 anyway (in spite of 
having different TYPE_PRECISION values) so Fortran wouldn't be able to 
distinguish them.  The thing that confuses me is how/when the rs6000 
backend defines __float128; it looks like the documentation in the GCC 
manual doesn't agree with the code, and I'm not sure what the intended 
behavior really is.  Is it possible that __float128 could end up defined 
but specifying a different type than TFmode, and if so is there a 
target-independent way to identify that situation?  Can the PowerPC 
experts help straighten me out?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso-c-binding.patch
Type: text/x-patch
Size: 3332 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210804/e4180b47/attachment.bin>

More information about the Gcc-patches mailing list