GDC release 0.23

[Daniel Keep]

David Friedman wrote:
> Sean Kelly wrote:
>> Anders F Björklund wrote:
>>
>>>>> GDC now supports 64-bit targets! A new x86_64 Linux binary is
>>>>> available and the MacOS X binary supports x86_64 and ppc64.
>>>>
>>>>
>>>> Excellent news! I'll try it on ppc64 Linux too (Fedora Core)
>>>
>>>
>>> Except for some strange (temporary?) build error with soft-float,
>>> it built just fine for powerpc64-unknown-linux-gnu (with FC5/PPC*)
>>
>>
>> That reminds me.  Is it really a good idea to map the GCC/PPC "long
>> double" to "real" in D?  I know this has come up before:
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/20790.html
>>
>> and the data type seems like an aberration.  Here is some more info:
>>
>> http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00499.html
>>
>> And from the ELF ABI:
>>
>>     This "Extended precision" differs from the IEEE 754 Standard
>>     in the following ways:
>>
>>     * The software support is restricted to round-to-nearest
>>       mode. Programs that use extended precision must ensure
>>       that this rounding mode is in effect when
>>       extended-precision calculations are performed.
>>     * Does not fully support the IEEE special numbers NaN and
>>       INF. These values are encoded in the high-order double
>>       value only. The low-order value is not significant.
>>     * Does not support the IEEE status flags for overflow,
>>       underflow, and other conditions. These flag have no
>>       meaning in this format.
>>
>> I can't claim to have the maths background of some folks here, but
>> this suggests to me that this 128-bit representation isn't truly
>> IEEE-754 compliant and therefore probably shouldn't be a default data
>> type in D?
>>
>>
>> Sean
> 
> The double+double type has caused me no end of trouble, but I think it
> is important to maintain interoperability with C.  If I make the D
> 'real' implementation IEEE double, there would be no way interact with C
> code that uses 'long double'.  I could add another floating point type
> for this purpose, but that would diverge from the D spec more than what
> I have now.
> 
> David

I might be off-base, but couldn't you do something like this?

> version( GDC )
>     pragma(gdc_enable, gdc_longdouble);
>
> // ...
>
> extern(C) gdc_longdouble foo(gdc_longdouble);

Yes, you'd be adding a new type, but at least it's hidden behind a
pragma.  Interfacing with C code is fairly important to D, but I'd hate
to have fp code that works fine under DMD and then mysteriously breaks
with gdc--I think compatibility with other D implementations should come
before interfacing with C.

Just my AU$0.02.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/