Re: Problem with DTYPE ABI regarding long double vs. __float128

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

FX,

On Sat, Jun 5, 2010 at 9:46 AM, FX <fxcoudert@gmail.com> wrote:
> May I respectfully ping this question, which received no answer?

I think that we sort of did not know what to say :-(

>>
>> While implementing __float128 support in gfortran, I came across what may be a very serious snag. The dtype in the array descriptor structure includes "sizeof(element_type)". As can be seen in libgfortran/libgfortran.h:
>>
>>> #define GFC_DTYPE_REAL_10 ?((GFC_DTYPE_REAL << GFC_DTYPE_TYPE_SHIFT) \
>>> ? | (sizeof(GFC_REAL_10) << GFC_DTYPE_SIZE_SHIFT))
>>> #define GFC_DTYPE_REAL_16 ((GFC_DTYPE_REAL << GFC_DTYPE_TYPE_SHIFT) \
>>> ? | (sizeof(GFC_REAL_16) << GFC_DTYPE_SIZE_SHIFT))
>>
>> The problem is that on x86_64, sizeof(long double) == sizeof(__float128) == 16. (On i386, we may get sizeof(long double) == 12 and sizeof(__float128) == 16 on some platforms, and sizeof(long double) == sizeof(__float128) == 16 on others).
>>
>> This is used in libgfortran to branch into different code paths in intrinsics like cshift (and probably other such cases). However, the sizeof information is not enough to distinguish the types, as explained above. The question becomes: do we really need to differentiate types based on dtype, or is sizeof enough? I think we really need to get the type back, and thus the array descriptor would need to be changed (which I know is planned anyway).
>>

I don't know how you can deal with this at the moment, other than to
generate specific instances of the library routines for __float128.

Of course, once the array descriptor business is done life will become
much easier.

Cheers

Paul


-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy