[Bug fortran/100917] Bind(c): errors handling long double real

["sandra at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917

--- Comment #6 from sandra at gcc dot gnu.org ---
I've been thinking some more about this issue.  It seems to me that a "proper"
solution is either (1) Add a kind field to the GFC descriptor or (2) Do away
with GFC descriptors and use the C descriptor layout and encodings everywhere. 
Both of these break ABI.  (2) is more work to implement but more maintainable
long term, also more efficient at runtime.

To be more specific about the problem here....  on x86 targets, real(kind=10)
in Fortran or long double in C is an 80-bit representation.  On 32-bit
processors it has size 12 but on 64-bit processors it needs to be padded to 16
bytes.  Thus, if we only have elem_len=16 in the descriptor, we can't tell if
it is the 80-bit representation or the true 128-bit _float128 representation
when that is also available.

For a workaround that does not change the ABI, the best ideas I've had are
either mapping CFI_type_long_double and CFI_type_float128 to the same value on
targets where the two types both have size 16, or one of them to a negative
value to indicate it's not interoperable on that target.  In practice it's
probably rare for user code to have to use the typecode to distinguish between
floating-point formats -- you define your C function to accept the type of
arguments you intend to pass into it.

Anyway, a workaround for the floating-point stuff still leaves the character
size vs character length problem unaccounted for.